PHP Session Timezone Not in Sync with SQL Timezone

matth

This morning I created some more shares and oddly enough, I now see one of the two shares I created this morning.

However, I can confirm that all of the links I have generated so far work, only one appears to show up here. For further clarity, the files I'm sharing are in nested folders in the Files section.

johnny

I think this my be a timezone thing, where it might not be set on the system but is set in ITFlow

Create a share link then go to the table shared items in phpmyadmin check the fields item created at and item expire at on the newly created share. see if these time match

matth

johnny Is phpmyadmin included with the install of ITFlow or is this something I'd install elsewhere? I tend to not touch SQL tables very often, ha

johnny

its not included in the script, my guess is the created date in set in UTC time, what is your system timezone set to?

matth

johnny

root@itflow:~# timedatectl status | grep "Time zone"

Time zone: America/Chicago (CST, -0600)

ITFlow also has the time zone set to America/Chicago as well via Localization settings.

Bigbug

matth have you restarted your server since it was set?

matth

Bigbug Yup, it's been restarted a handful of times since it was deployed.

Some additional info about my setup:

My ITFlow instance is an Ubuntu 24.04 LXC container running on Proxmox. Used the install script to get it set up, but I think it was before the most recent re-write. Nothing fancy other than that. Timezone on server and ITFlow were both set during setup.

johnny

Just released a significant, long-awaited fix:

itflow-org/itflowc41b391

Issue Summary: While the PHP timezone was correctly set as configured, the MySQL timezone wasn’t synchronized, so fields like created_at, updated_at, and archived_at were defaulting to UTC (UTC-0) instead of the specified timezone (e.g., America/New_York UTC-5). This led to issues in ITFlow where data wouldn’t display correctly until it matched your timezone.

By default, MySQL doesn’t automatically adopt the system timezone, and it defaults to UTC unless explicitly configured.

Resolution: Setting the MySQL and system timezone is now optional. We now rely entirely on the PHP session timezone as configured within the app.

This went unnoticed on our end since our instances on HestiaCP set the SQL timezone to match the selected system timezone by default.

matth

johnny Thanks for this!

Some questions I have:

Does this mean that future shares should work correctly?
What about existing ones?
Is there anything I need to do on my end?

johnny

matth Nothing to worry about let it ride out

« Previous Page