3 ms·

I work on a room and equipment reservation system. To my users, the time of the booking is always the time on the clock on the wall where the booking is. It nev

by Joeri 10y ago

I work on a room and equipment reservation system. To my users, the time of the booking is always the time on the clock on the wall where the booking is. It never changes, regardless of what insanity the time zones go through. So, it is stored twice, as a wall clock timestamp without tz, which is authorative, and as utc, derived every time the wall clock time is saved. It is a best of both worlds solution, utc for when we need to compare against now (to know when a booking becomes final) and wall clock time as authorative source and for user display. No disasters so far. ;)

deleted 10y ago
[deleted]
joshstrange 10y ago
This is an acceptable solution in your situation it wouldn't be in mine and only storing local time is never acceptable IMHO.
- pmontra 10y ago
  He's storing both. Actually that's what I did in a system to store events. Clients sent both their local time and UTC. UTC was used to sort events and local time to display the event time to users, in the time zone the event was generated into, forever. I think I also stored the UTC timestamp of when the server received the event.
- andrewf 10y ago
  I disagree in cases like this, where local wall time is the source of truth. I would go further than OP and not keep UTC time around in a separate column either. Why? On March 13 last year, Chile announced a new daylight savings change, to take place on May 15. [1] Let's say I already had an appointment somewhere for 3:00pm on May 21. When the timezone change was announced, that reservation is still at 3:00pm local. It is not still at the same time in UTC. utc_time is derived from local_time and timezone, not the other way around. (I am generally a fire-breathing advocate for UTC everywhere) [1] http://codeofmatt.com/2016/04/23/on-the-timing-of-time-zone-changes/ http://codeofmatt.com/2016/04/23/on-the-timing-of-time-zone-...
  - shakna 10y ago
    Would not epoch time then make the most sense?

by Joeri 10y ago

deleted 10y ago

[deleted]

joshstrange 10y ago

This is an acceptable solution in your situation it wouldn't be in mine and only storing local time is never acceptable IMHO.

pmontra 10y ago
He's storing both. Actually that's what I did in a system to store events. Clients sent both their local time and UTC. UTC was used to sort events and local time to display the event time to users, in the time zone the event was generated into, forever. I think I also stored the UTC timestamp of when the server received the event.
andrewf 10y ago
I disagree in cases like this, where local wall time is the source of truth. I would go further than OP and not keep UTC time around in a separate column either. Why? On March 13 last year, Chile announced a new daylight savings change, to take place on May 15. [1] Let's say I already had an appointment somewhere for 3:00pm on May 21. When the timezone change was announced, that reservation is still at 3:00pm local. It is not still at the same time in UTC. utc_time is derived from local_time and timezone, not the other way around. (I am generally a fire-breathing advocate for UTC everywhere) [1] http://codeofmatt.com/2016/04/23/on-the-timing-of-time-zone-changes/ http://codeofmatt.com/2016/04/23/on-the-timing-of-time-zone-...
- shakna 10y ago
  Would not epoch time then make the most sense?