5 ms·
No, No, No, NO. Look I know TZ's and dates are hard, I work with them quite regularly, I have written code to handle things like recurring items, and I have wr
by joshstrange 10y ago
No, No, No, NO.
Look I know TZ's and dates are hard, I work with them quite regularly, I have written code to handle things like recurring items, and I have written a lot of code around knowing what TZ to show a date in to an end user (in my case you have to deal with things happening in a participant's TZ, their supervisor's TZ, our call center's TZ, and whatever the TZ is of the browser the end user is accessing the site from, all of which could be different). A bad UTC time due to mismatched timezone databases is by far the least of my worries, in fact it's not even on my radar nor do I plan to add it to it. You HAVE to standardize, period. UTC makes the most sense (epoch timestamps if you can get away with it) and it's up to the client to format that however they want (moment.js is your friend if you are a web dev). Yes, keep your TZ databases up to date and know which DB your software is using but use UTC. Anything else is a recipe for disaster.
- Joeri 10y agoI 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 agoThis 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?
- amichal 10y agoStoring and comparing UTC is the minimum for sure but you often need to store local time and zone as entered and sometimes you do need to change what that is in UTC after the fact. I worked on a internationally-focused scheduling application with clients in multiple timezones doing recurring events in future. Israeli customer's computers for instance could not be trusted to tell us the correct timezone so we needed to ask explicitly their intent then due the 'Israel Summer Time's offset being a political issue[1] we would have to fix up our calculations after the fact: [1] https://en.wikipedia.org/wiki/Israel_Summer_Time#2005.E2.80.932012 https://en.wikipedia.org/wiki/Israel_Summer_Time#2005.E2.80....