Your best practices will vary of course. This article makes a lot of assumptions about what app is being built.
Database: Save the user timezone in the database. Save this as in the Olson standard or something similar against the user. Don’t store numeric timezone offsets or daylight savings dates. The user may move countries and timezones so it might also be a good idea to save a history of timezone changes. Also store the current user timezone next to datetime columns, so we know his/her timezone at that particular point in history.
Database: Store UTC and local time, as well as the user’s timezone in each row Why is it a this or that proposition? As mentioned above, storing the user’s timezone in each row (as opposed to only stored against the user’s profile) gives higher contextual specificity and hopefully is lossless for your purposes.
Database: Store the time component and not just the date. Or store the UNIX timestamp. For example store 2019-01-01 00:00:00 and not 2019-01-01. Without a time component, it would probably be reasonable to assume that 2019-01-01 implies 2019-01-01 00:00:00, but I’d rather be explicit and consistent. In addition, it makes no sense to apply a timezone when there is no time component.
Operating System: Set the OS timezone to UTC. If files and logs are being stored across multiple machines or containers, it is useful to have a common date time when debugging problems to reduce potential confusion.
Code: Set the application timezone to UTC regardless of where the customers are. If the OS timezone is set to UTC, you can use that directly, but don’t make an implicit assumption so always set it manually. In PHP frameworks such as Laravel, configuration files allow you to set application wide timezones
Code: Create presentation layer helper functions to convert the date stored in the database to times into the user’s timezone (or whatever target timezone is desired).
General: Use existing databases and libraries. The classic reinventing the wheel syndrome. Timezone databases i.e. tzdata and plenty of high quality date & time parsing tools already exist. There may be good reasons to do thing manually such as calculating offsets, whether it’s for performance reasons or some other, but
In the context of PHP,
strtotime is a function that returns the UNIX timestamp when given a string. A UNIX timestamp is by its very definition, the number of seconds elapsed since Jan 1, 1970 in UTC. It is not the seconds elapsed since Jan 1, 1970 in any other timezone. If you give
strtotime a string e.g.
2019-01-01 09:00:00, it will return the number of seconds since Jan 1, 1970 UTC relative to the timezone defined in the PHP configuration. In other words it will internally treat
2019-01-01 09:00:00 as the time of the timezone in the PHP config, do its internal magic to convert to UTC then get the seconds elapsed since Jan 1, 1970 UTC.