3 ms·
UTC or Unix epoch are good for datetimes in the past, e.g. for logging events. They're not good for future datetimes, e.g. for recording appointments. Because
by em500 6y ago
UTC or Unix epoch are good for datetimes in the past, e.g. for logging events. They're not good for future datetimes, e.g. for recording appointments.
Because in case of local timezone policy changes, in the vast majority of cases the intention is for the future event to stay constant in the local timezone, and be changed in UTC / epoch. If for example you made the mistake of storing store opening hours in UTC and translate it to local time in the UI, you will be showing the wrong time.
For appointments, you need both the datetime and the location/timezone. In case of cross-timezone appointments, e.g. virtual meetings, if there are timezone policy changes the issue cannot be resolved without rescheduling the event for some participants.
- Joker_vD 6y agoAnd for the event in the past, respectively, you need datetime and the then-effective offset, not timezone, if you want to know the "what was the local time on the actual physical wall clock?". Unless you're sure the tzdata were correct when the timestamp was taken, and your current tzdata have correct historical info, you can't just take UTC timestamp+timezone and convert it to local time. And I've seen enough machines that had deliberately wrong timezones for some time.
- kevinmgranger 6y agoDoesn't the olson DB track when offsets changed based on UTC time, and thus UTC timestamp+timezone is enough? (If your datetime library handles historical information in the DB correctly, that is!)
- Joker_vD 6y agoIt does, but, eh, I mean, read the accepted answer: apparently, the past is rather unpredictable.
- klodolph 6y ago> UTC or Unix epoch are good for datetimes in the past, e.g. for logging events. Unix epoch is known not to be good enough for some scientific applications :-/
- egsmi 6y agoThat's interesting. Can you point to an example? Is it a resolution problem?
- klodolph 6y agoIt’s a resolution problem if you want to measure something within 1s, which is fairly tame and reasonable. Like, let's say you’re measuring the time between two events, and you’re logging a stream of them. If you use Unix timestamp, the timer will jump during a leap second. This is because a day in Unix time is always exactly 86,400 “seconds”, but an actual civil day may be from 86,399 to 86,401 seconds. (It has never been 86,399 seconds, but it “could” be.) So you should probably be using TAI. UTC is theoretically good enough but it is inconvenient to use because of the leap seconds. Unix time is a bit broken. It is actually very easy to use TAI. You just need a GPS receiver. TAI is a fixed offset from GPS time (TAI = GPS + 19 seconds).