4 ms·
This is an acceptable solution in your situation it wouldn't be in mine and only storing local time is never acceptable IMHO.
by 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 agoHe'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 agoI 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 agoWould not epoch time then make the most sense?