Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I have a device which will be sending information when a certain event occurs. The application is expected to work globally and so the device will send the time in its local timezone. For this field should I go for dateTime, dateTimeTz or Timestamp?
My reasoning is that if the device is local for that user and the user is in the same timezone of the device I can use dateTime?
I usually store all times in UTC so if I need to do any translation I can convert it with users time zone. It would be confusing to store based on devices local time. So when the event happens, I guess device will contact your app and your app can store that time in the database as UTC.
Nice video The Problem with Time & Timezones https://www.youtube.com/watch?v=-5wpm-gesOY
i would prefer using timestamp, as it standardize the format for all, and have the timezone cater in either in additional "user_preference" table or get the local timezone of the pc.... it's more flexible to fit all different timezone case...
timestamp has a limit until year 2038, while datetime goes all the way til 9999.
If you are using MySQL, datetimeTz is the same as datetime, both are just datetime if you examine the table.
One of the common confusion about time and zones is that we need to somehow set/store the zone. I beg to differ, there is only 1 flow of time, i.e. the conversion of time between any zone is a one to one relation.
So, storage should always be based on UTC and display should be dynamic, dependent on user's locale.
Both datetime and timestamp records just the point in the flow of time. It lets the code decide which zone to translate it to and display it.
datetimeTz stores not only the point in the flow of time, but also the zone (read: location) in certain database engines. Frankly, I cannot think of any use case where this is useful. Storing the time and location separately might make the code and logic easier to read.
To answer your question, I think datetime is a better approach since 18 years isn't all that far away.
Yup. Always, always store dates and times as UTC in your database. If you need to show values in a different timezone, then do so based on a user preference. When you start trying to convert dates and times stored in one timezone to another, it only leads to problems.
As for the original question, use datetime, @lukegalea16. As pointed out, a timestamp has a finite upper limit with it being a UNIX timestamp.
Is it possible to automatically detect the user's time zone from Laravel/PHP (from where his/her request is being made)? This can then be used to automatically convert the stored UTC timestamps to his/her locale time. Or would you suggest storing the user's preferred time zone in a DB?
@lukegalea16 Yeah, you’d need to let the user set their timezone preference in their account settings.
Timezone is not something you can detect server-side, but you can do it client-side. So most sites will use JavaScript to determine the timezone set on the client, and then use that to select a default option in a timezone list.
You could use GeoIP to narrow down location, and set that as the initial timezone, and further configurable by the user, but I would think it is just a delightful feature, not necessarily impactful. :)
Please or to participate in this conversation.