7 ms·
I think summary here is that if you are storing an exact moment in time then UTC does the job. If however you are storing a future date and time in a certain lo
by samwillis 5y ago
I think summary here is that if you are storing an exact moment in time then UTC does the job. If however you are storing a future date and time in a certain location, due to the uncertainty about future daylight saving time changes you have to save it with time zone information in order to adjust for future changes to that system.
I suppose it’s the difference between exact time and social/political time (there is probably a better term for that).
- em3rgent0rdr 5y ago> "social/political time (there is probably a better term for that)." The better term is "civil time": https://en.wikipedia.org/wiki/Civil_time https://en.wikipedia.org/wiki/Civil_time
- masklinn 5y ago> due to the uncertainty about future daylight saving time changes It’s not just DST, it’s any TZ-related changes: locations can change TZ for other reasons than dst. > I suppose it’s the difference between exact time and social/political time. There’s really no such thing as exact time. The closest is UT1, and it’s not really practical for normal applications.
- samwillis 5y ago> It’s not just DST, it’s any TZ-related changes: locations can change TZ fir other reasons than dst. Exactly, and for that time zone info will not be enough, you would need geographic coordinates.
- deleted 5y ago[deleted]
- spacemanmatt 5y agoTo be more accurate you should also store relative velocity so the Lorentz transformation can be applied at display time
- scatters 5y agoGeographic coordinates can change as well (earthquakes; office moves). But that's why the tzdb uses major/dominant city names.
- samwillis 5y agoIssue with that is borders move, and with that time zones. So you may be in the “Europe/London” time zone now. But the north of England could annex itself and create a new time zone “Europe/Manchester”…
- ycombobreaker 5y agoIn the great schism of England, the meeting organizer fled to central Europe, and one of the primary stakeholders died. The meeting had to be rescheduled.
- masklinn 5y agoA more realistic issue is that Scotland currently doesn’t have an entry in the tzdb.
- layer8 5y agoDepends on what you mean by time zone info. A time zone identifier like "Europe/Paris" will usually be sufficient.
- kalleboo 5y agoTime zone identifiers are created once an area stops matching the previously best-matched identifier. Like right now maybe all of France uses Europe/Paris, but if southern France decides to secede and change their timezone by an hour, they would all have to re-configure from Europe/Paris to Europe/Toulouse. The existence of a bunch of currently seemingly-redundant time zone identifiers are a testament to the history of this. So the only 100% future-proof solution is geographical coordinates that can be looked up in a continually-updated database.
- layer8 5y ago> geographical coordinates So, what do you do for a remote meeting with participants in different places? You’d have to decide on one location. Specifying Paris when you are really in Toulouse isn’t much different. Yes, your meeting is now bound to Paris time, but at least it remains consistent with that. Furthermore, having had to work with call routing based on geolocation, I can tell you that geo coordinates aren’t always enough, due to inaccurate zip code and area code divisions and other factors.
- wongarsu 5y ago> There’s really no such thing as exact time. The closest is UT1, and it’s not really practical for normal applications. I would have defined TAI (International Atomic Time) as "exact time". Of course with it being an average of clocks it only really exists in hindsight and isn't perfect either, but if you only need accuracy on the order of hundreds of nanoseconds and are on earth's surface it's very practical and easy to get anywhere with a GPS receiver. And UTC is only slightly more messy, with its offset from TAI to keep it in sync with unpredictable UT1.
- tialaramex 5y agoRight. It's crazy that we welded civil time to UT1 rather than TAI. TAI is ours, we made it, here on this rock we're all stuck on. Because time is necessarily relative to your position that's the best we could hope for. The astronomers are welcome to UT1, it's useful for them and I have no problem with that, but it's crazy to keep tweaking UTC to match UT1 rather than just letting it plod along mechanically forever with TAI. Abolish leap seconds.
- layer8 5y agoThis will create problems in the long term, because the delta-T due to the deceleration of earth’s rotation due to tidal friction increases quadratically [1]. Not saying it wouldn’t be practical, but that’s the debate, along with astronomer’s needs, satellite navigation etc. You can’t just ignore the relationship with earth’s rotation. [1] e.g. https://www.researchgate.net/figure/Observations-and-parabolic-t-of-T-versus-time-since-1620-after-Stephenson-and-Morrison_fig1_231080674 https://www.researchgate.net/figure/Observations-and-parabol...
- tialaramex 5y ago> You can’t just ignore the relationship with earth’s rotation. Doing so is, in fact, the point of abolishing leap seconds. Imagine that we have leap seconds, and the very worst case conceivable happens for an entire century. 100 summer leap seconds and 100 winter leap seconds, that's a total of just over three minutes by 2122. Can we tolerate such a disruption to the lives of ordinary people? Try asking anybody who lives in a place with Daylight Saving or "Summer" Time. They have twenty times more disruption and that happens twice every single year.
- thrdbndndn 5y agoI probably should read into details, but I don't get it from the summary at least. How would future time zone change or DST change affect it at all? Is it about your pre-defined time would no longer be aligned with a nice "local time" like 0:00? Because things would still happen at the exactly same "moment" (absolute time or time delta from now) in UTC regardless any TZ change isn't it?
- pretendgeneer 5y agoThe difference is something like storing your comment was made at 2022-03-13+10:40. Which the time zone has been set and will always be the same at as it's in the past vs "set an alarm for 2023-03-13+6:00" I want the to happen at 6:00am whether or not my country continues to observe day light saving time.
- 0x0 5y agoDoesn't help you much if you stored an UTC for a future meeting, then the TZ rules change, and then you show up an hour late.
- tshaddox 5y agoTrue, although if your meeting will be attended by people in multiple time zones, you need to declare the time in some absolute sense anyway.
- liversage 5y agoYou have a timestamp in the future for example the time when a session at a conference starts. If to want to store this as UTC you will have to convert it from the local timezone of the conference location. You can always go back from the UTC timestamp to the local timestamp by performing the reverse conversion EXCEPT if the conversion involves daylight savings and the rule changes between now and the event in the future. While rare, daylight savings rules sometimes do change. I guess even local timezone offsets might change once in a while. When this happens the conversion back from UTC to the local time will be wrong unless you keep track of more than the UTC timestamp.
- brewmarche 5y agoI’ve used wall clock time for the latter. Because what matters is the time in the wall clock for future events/meetings. I don’t know where exactly I picked up the word but I’ve used it here https://news.ycombinator.com/item?id=22968405 https://news.ycombinator.com/item?id=22968405
- Joeri 5y agoThere are basically three types of time: coordinated time, based on atomic clocks, zoned time, derived from coordinated time by applying a time zone rule to calculate an offset, and wall clock time. The latter two are often lumped together as local time but are not in practice the same thing. TZ rules are one way, you can derive zoned time reliably from utc, but not the other way around unless you already know the offset. That’s why seemingly storing utc is best, because you can apply whatever tz rule you want. But, because tz rules are decided by politicians (dst, ramadan, date line shifts, it gets pretty weird, …) and often with little advance notice, tz rule databases are often wrong in practice, which means storing only utc and getting zoned time back out of it reliably is hard. That’s why storing iso timestamps with offsets is best. It preserves both utc and intended local (zoned) time at the time of storing, even if the tz database then changes. But this is not the author’s problem. They’re dealing with wall clock time. They want to store 9 am and have it always be 9 am, no matter what happens with time zones. That is easy: store the timestamp without tz info. But, the hard part is knowing the instant in time (in coordinated time). Wall clock times may occur twice, so there is no single reliable way to get utc out of it, and even when calculating utc the result can be wrong or become wrong due to the political insanity that is zoned time so it is dangerous to store it and rely on it. You see this problem with anything that schedules people or resources. Something scheduled at 9 am is always 9 am, but if the system needs to send a reminder at 9 am, when do you schedule it? There are no solutions I’m aware of without edge cases. I solved this for a reservation system by storing wall clock time without offsets and the time zone (id) of the resource separately, and then calculating zoned time for that zone and comparing it with the stored wall clock time every time the instant in time mattered. It worked but was tricky to code.
- ivan_gammel 5y ago> Wall clock times may occur twice Rule number one and the only rule about wall clock times is that they are display style only and must never be stored. Local times must use 24 hour format.
- brewmarche 5y agoI think they’re talking about times occurring twice due to DST.
- moltke 5y agoYeah, also you can't compare UTC times without an almanac generated by a random natural process which means even without the cultural/political problem UTC is still by definition uncertain for future dates. AST is arguably better for this but doesn't get around the political problem.
- samwillis 5y agoI wander if we need a new version of ISO8601 which includes the TZ location rather than just an offset. Something like: 2022-03-13T07:21:39@Europe/London I suppose that’s also problematic if the location changes to a different time zone due to boundary changes. Maybe we need a coordinate (and planetary body) system: 2022-03-13T07:21:39@Earth/51.5055853,-0.1014699 We need that full frame of reference to be sure we will be correct in future.
- dzikimarian 5y agoWell, there's also continental drift :-) honestly everything we do in IT is approximation - some of them are worth accounting for, many are not - at least for most of us.
- mqus 5y agoI think tzdata timezone locations (like Europe/London) are fully sufficient, since they are tracking the clock everyone uses in that location. If the boundaries change, then so will the clock for everyone in that boundary, so the time probably won't be right regardless. I think coordinates are not completely right, since the time context is mostly political/cultural, not geographic. I don't have examples but I can easily imagine a border region specifying some event in a time that is referencing the region across the border.
- samwillis 5y ago> I think coordinates are not completely right, since the time context is mostly political/cultural, not geographic. My point was that geopolitical boundaries change and so what the “major” city near by for reference is now, may be wrong in the future. Coordinates ensure it’s completely future proof from boundary changes and correct to an exact location.
- nly 5y agoThere will always be outliers. If you're scheduling a meeting in a small town on the border of 2 countries that honor different time-zones, then you're probably just going to have to pick one to be the source of truth, and hope it's the other side causing the disruption (changing their clocks) and they'll pay for the administrative overhead.
- wpietri 5y agoYeah, human time is much more complicated than the strict linear clock. For certain past periods the former can generally be destructively mapped onto the latter. But as with a lot of things, programmers tend to confuse human intent with the post-intent "objective" record of the thing. Which I get, as the latter is much easier to deal with.
- alecbz 5y agoYeah, this is exactly the difference between what I’d call “timestamps” (something that represents a particular instant in time), and what I’d call “datetimes”, things like “midnight on Jan 1, 2019”. I worked at an insurance startup that stored coverage period start/ends as timestamps, which ended up being semantically wrong. The coverage ends at midnight of the next year, wherever _you_ (technically the provider, I think) are. So there is no one single instant in time when coverage ends; a timestamp is the wrong data type for representing this.
- lamontcg 5y agoIf you've worked on a distributed team that had members in the UK/EU and the USA then you've run into this before when scheduling meetings. A 10am PDT America/Los_Angeles meeting is different from a 6pm BST Europe/London meeting which is different from a 5pm GMT meeting and those will jump around by an hour depending on time changes. If the bulk of your team is in Seattle then you probably want to pick the US timezone for the meeting and not GMT or London. If you have a manager in London, though, who sets up the meeting time in their local timezone then Seattle employees will notice tomorrow that the meeting is a hour later in Seattle than it normally is. If everyone shitcanned clocks jumping around twice a year this craziness would end.
- throwaway894345 5y agoI think this is the inverse problem. In this case, timestamp is the appropriate data structure for the meeting and each person's client needs to convert it back to local time, accounting for things like daylight savings time and so on.
- marcan_42 5y agoRecurring meetings cannot be expressed as timestamps (unless you want all the humans to hate you). The recurrence has to be expressed in terms of local time (and date/day of week) in some (ideally per-event) timezone.
- 5y ago
- karmakaze 5y agoSometimes local date-time (with optionally a location) is better. If I tag a photo as Christmas morning and upload it to a global photosharing site, I'd expect something that says when I took it in my local time and optionally location. I don't care about UTC or the photo's timestamp in the viewers timezone. If you want to make it complicated store UTC + offset (not timezone).
- 0x20cowboy 5y agoJust store an offset amount from the start point, create a tangent line against the curve of time, and then as the limit approaches zero… :)
- techdragon 5y agoI called this out in the “how all this relates to programming” part of a presentation I did a couple of years ago on the history of timekeeping.