From eFiction 1.0 to 3.5.3, timestamps have been stored using the datetime data type with the server's set time zone's data (and not UTC 0). They would be parsed through eFiction itself using MySQL/MariaDB's UNIX_TIMESTAMP() and would be inserted as datetime with the reference of now() .

Note: UNIX_TIMESTAMP() always references them in UTC then the system converts that back to local time...

From eFiction 3.5.5 on, a structural upgrade has changed how timestamps are stored, from the datetime data type to an int(10) data type and the existing datetime values are converted to the actual Unix timestamp. The UNIX_TIMESTAMP() references as a result are removed. The now() references were also replaced with time() .

Upgrading from 3.5.3 to 3.5.5 should convert the stored datetime values properly... as long as the server's hardware was set with UTC in mind and the server's time zone was never changed in any way before conversion. Normally, you'd think of the timestamp data type (yes, there is another one)... but there are limitations, which are mentioned later here.

The current methods in version 3.5.5 and newer are a more proper way to store and read timestamps with MySQL/MariaDB since its datetime data type can go to year 9999, but does not even store time zone values. There is also the issue of the timestamp data type handling on older MySQL/MariaDB database server versions... you can store the Unix timestamp in human-readable format (in UTC, of course) with this data type, but those values (predictably) end at the signed 32-bit Unix epoch, or the Year 2038 problem, especially if using the 32-bit releases. Going past the signed 32-bit Unix epoch limit with those older database versions results in a null value, hence eFiction's historical use of the datetime data type, despite its own limitations.

As for the timestamp data type now... Newer MariaDB server versions now use an unsigned 32-bit value, so the limit goes to the next century instead, around the year 2106 — this is to not cause issues with timestamp data on existing databases; and newer MySQL server versions now use a signed 64-bit value, so the limit goes to ~292 billion years from point 0 of the Unix epoch. However, older database server versions are still running in production to this day, which will eventually cause issues when using the timestamp data type.

...You can now see why eFiction 3.5.5 and newer store timestamps as a Unix timestamp using an int(10) data type and parsed through eFiction itself with time() .