5 ms·
Storing UTC is not a silver bullet (2019)
- max_ 2y agoWe should just drop all other time zones and use UTC
- kjrfghslkdjfl 2y agoWe should just actually understand the concepts we're working with.
- usrnm 2y agoBecause making programmers happy is so much more important than making users happy?
- rafaelcosta 2y agoLet's go back to each city having its own time. _Because making train companies happy is so much more important than making users happy?_ All jokes and "snarkiness" aside, it's just a matter of habit. If the whole world used UTC and working hours/social time were set differently per-country, I bet we'd get used to it eventually.
- dsego 2y agoI don't know, you'd still need to coordinate based on local time, let's say I want to set up a meeting with colleagues from different time zones at 10. I have no idea what time of day that is for them, are they sleeping, having lunch, etc. With time zones, I can look up the time offset, with universal time I'd have to check their location and what time of day it is for them, which could be confusing, how do you map it exactly, bed time, lunch time, one hour before lunch time, two hours after bed time? The other problem is that I don't think habits would be easy to change. Right now people in some european countries want to stay permanently on summer time to have more daylight after work. We could just as easily stay on winter time and have everyone go to work earlier, shops could open at 7 instead of 8, etc. But for some reason this isn't considered, so I assume it's easier to enact all year DST than to change working hours.
- iggldiggl 2y agoAnother thing is that having the change of calendar date in the middle of your waking hours is rather annoying and potentially confusing, and everybody in the world not living near wherever the meridian ends up will be subjected to that. (Because in that case a single calendar date can refer either to solar date A in the afternoon/evening, or solar date B in the morning). Like should public holidays e.g. start and end right in the middle of the solar day because that's when midnight UTC happens locally? Do you reintroduce time zones by the back door by defining a local start/end time for day-based events to align them back to the solar day?
- WorldMaker 2y agoYou are joking, but I think City-based timezones would work well on today's internet. We have better than ever computers to do time math and scheduling/coordination for us, let's leverage that. It's easier than ever to go to more timezones rather than fewer, because we don't have to make train companies happy anymore and because some people would get better sleep if their local time was closer to their solar time and because DST is easier to get rid of with smaller timezones. (DST is, among other things, a hack around our timezones are too wide.) The IANA timezones are even already primarily city-based, so a lot of software wouldn't even need to update anything but their IANA tzdb. Now might be a great time to do something like that. It doesn't sound like a serious proposal, but there would be interesting benefits to city-based timezones again in the modern world. We actually have the technology to scale smaller timezones now. We aren't relying on mechanical clocks like the train companies were and paper calendars like early multi-timezone companies like GE were. We could make local time resemble solar time a lot more again, and solve it as a software problem.
- max_ 2y agoNot just developers but everyone. The world has changed and we often collaborate globally. I remember we had todo this zoom meeting. - 1 guy from USA - 1 guy from Europe - 1 guy from East Africa - 1 guy from Singapore It was extremely difficult to schedule a meeting off head. When the it was okay for the guy from East Africa to meet it was like 5 am in Singapore. Even if you successfully organise the meeting. The organizer having to translate all times to the respective time zones of the audience is just so painful. Okay now we have Calendly a tool we have to sign up for. But conversations of scheduling would be much easier if everyone in the world used UTC
- em500 2y ago1. People who never collaborate globally/cross TZ vastly outnumber those who do. And the people who do can already use UTC right now. 2. Making everyone in the world to use UTC is going to make everything less convenient for everyone who lives a few hours away from the UTC TZ (i.e., most of the world). Because in UTC many of their daily events are going to span 2 dates/weekdays. 3. For the handful of people who need to schedule cross TZ meetings there's https://www.timeanddate.com/worldclock/meeting.html https://www.timeanddate.com/worldclock/meeting.html, no sign up required.
- WorldMaker 2y agoThat was some of the arguments behind the interesting but failed experiment that was Swatch Internet Time: https://en.wikipedia.org/wiki/Swatch_Internet_Time https://en.wikipedia.org/wiki/Swatch_Internet_Time
- lxgr 2y ago> So from November 1st 2021 onwards, the UTC offset of each country will be fixed – but there may be countries which currently always have the same offset as each other, and will have different offsets from some point in 2021. (For example, France could use winter time and Germany could use summer time.) It’s worth noting that this did not end up happening. Maybe a 2019 tag could be added to the title?
- skrebbel 2y agoThat doesn’t affect the point of the article at all though. Timezones change, so if you’re storing a datetime of something that happens at a particular physical place, store it with that place’s timezone (not offset) (EDIT And even eg scheduled video calls take place in physical places, so in practice future events of any kind are best stored in localtime with the relevant user’s timezone attached)
- watt 2y ago> scheduled video calls take place in physical places have you ever travelled and had to join the call from a different country, different time zone? the calendars usually help you to translate the call's timezone to your local timezone, but they only can do that if they can determine the offsets.
- mordae 2y agoJust convert using most up-to-date source time zone into UTC, then proceed as usual. The point is that the event is not actually fixed in time, but affected by local law that can arbitrarily move times of all scheduled meetings by an hour or so. It would be nice if get get rid of DST so that we wouldn't have to special case situations that only happen once every half century, though.
- skrebbel 2y agoYeah so you determine the offset at display time. Store “Europe/Amsterdam”, not “UTC+1” so that if Amsterdam (or likelier, the Netherlands) decides to shift timezone or move the DST change dates or something insane like that, before the event occurs, you can trivially take that into account by updating to the newest tzdata file. Converting from timezone to offset is a lossy conversion.
- deleted 2y ago[deleted]
- aljgz 2y agoJon Skeet is one of the two greatest of my software engineering heroes. The other one is Andrew Hejlsberg. Just by reading some of his answers on SO, or by reading his C# in depth book, or his talks and blogs, I learned how you can think of scenarios where a design falls short, and to think of pros and cons rather than right and wrong. He has a clear mind on things, and a very direct style of writing.
- noir_lord 2y agoDid you mean Anders? My all time favourite programmer - everything he's worked on back to Turbo Pascal has shaped my career.
- aljgz 2y agoDarn yes, thanks, too late to edit. Agree about him. He has style. When I was learning c#, every convention, every name made perfect sense.
- noir_lord 2y agoSame feeling I had back in the 80's as a kid learning Turbo Pascal - he just views the world the way a much smarter version of me would :).
- kjrfghslkdjfl 2y agoIf you want to represent a point in time, use UTC. If you want to represent a point in a calendar, use local timezone.
- dsego 2y agoBut there is no point in time without a location and I think this is the point of the article. The quirk is that the offset to UTC might not be static because of timezone changes, and saving UTC doesn't capture that.
- kjrfghslkdjfl 2y agoYou're confusing time with calendar. If I want to meet an alien species in Jupiter we're not going to coordinate using Earth's calendar. Doesn't mean it's impossible to meet just because they don't know Earth's calendar, we just have to specify a point in TIME without resorting to Earth's calendars. And points in TIME don't depend on timezone changes. Points in the calendar do. A "timezone" is a map from point in time to point in the calendar. And a "timezone change" is an operation that takes a point in time from one point in the calendar to a different point in the calendar. > The quirk is that the offset to UTC might not be static because of timezone changes, An offset to UTC by definition does not depend on timezone, the same way that integers don't depend on timezones. 5 is 5 regardless of the timezone. If I say offset=3711, that has nothing to do with timezones. You're confusing time with calendar.
- dsego 2y agoI don't think aliens would care about UTC. And it seems a bit pedantic to separate it, humans tend to store times related to events on Earth. > If you want to represent a point in a calendar, use local timezone. And actually, going back to the original comment, this part was covered by the article. Storing timezone doesn't cover the case of a location switching between timezones. So it seems the article can't be summed up in a simple rule like the original comment contends.
- 2y ago
- gushogg-blake 2y agoThere was some interesting discussion around what data structures you should store at https://news.ycombinator.com/item?id=40933110 https://news.ycombinator.com/item?id=40933110 (Engineering principles for building financial systems).
- tomphoolery 2y agoIs anyone else sick of the "European Parliament" deciding the rules for the rest of the Internet? I know I sound like a dumbass American here, but I feel like there's gotta be a way for the EU to get what they want without bothering everyone else in the world constantly... The issue is that they keep enacting laws that have good intentions, but are written poorly and without any sort of experience in the technical realm. This results in the laws' implementation being filled with weird loopholes that you can use to get around the extra work while still maintaining the legality, but completely missing the intention of the law in the first place. It just seems like a massive waste of time to me.
- mordae 2y agoEU pondering daylight saving in its territory bothers you? Well, too bad.
- TheNewAndy 2y agoHow do European timezone rules bother you?
- groestl 2y agoThat has nothing to do with the European Parliament. Or not in the general case. If you're interested, dig yourself into the changelog of tzdata. Timezones are inherently political.
- pjc50 2y agoIs anyone else sick of the US deciding the rules for the rest of the Internet? I'm fed up of American advertiser-friendly doctrine deciding what is acceptable content anywhere in the world. (joking, but this is kind of an unsolveable problem of having a global network without a global governance system, you're going to run into mismatches)
- seszett 2y agoI'm not really sure what you mean, changing the timezone of a country is certainly their prerogative and "technical experience" doesn't really have anything to do with it. The EU is one example here but many other countries have timezone/DST changes, the EU is one of the places that don't change timezones often. The US on the other hand has such variety in timezones and DST observance, not even following state borders, that it's a real pain to support.
- Terr_ 2y agoUltimately, the issue is separating and capturing user intent between two major categories: 1. Events that are socially bound to a context, and capturing that contract or triggering rules, e.g. "Whenever the nation of Ruritania declares March 3rd end of workday". 2. Events that occur a fixed and knowable internal from "now." It is complicated further by the fact that many users won't really be aware of their own varying different intentions.
- globular-toast 2y agoStoring UTC for future times has never made much sense. But people still think UTC is the silver bullet for storing timestamps, ie. for records of past events. But even this is prone to failure. At some point someone will ask the question "how many events happened before lunch time?" This is a very clear and reasonable question to ask, but when is lunch time? Unfortunately many implementations simply store the UTC timestamp and throw away any time zone information (e.g. postgres TIMESTAMP WITH TIME ZONE, despite the misleading name). There are two ways around it: store the user's current time zone in another field, or record it in something like ISO8601 as local time with offset (although this only records the offset, not the IANA time zone). Both options have pros and cons. I wish implementations supported the basic tuple of (timestamp, timezone) where timestamp is a Unix-style timestamp (a number). The timezone can be ignored when it isn't needed, but is always there when it is. The difficulty is how to store the timezone and I'm sure there are numerous other issues with this.
- wood_spirit 2y agoAlmost always you store some kind of log with timestamps when decisions were made or events generated or whatever. Is there any library that can translate utc to local time where it addresses time offset changes based on the knowing the utc when the future time was decided upon?
- cbsmith 2y agoThis article always bugged me, because it needlessly makes things seem complicated. There are times when you are trying to represent a moment in time, and then there are times when you are trying to represent a moment in a calendar (which is not the same as a moment in time). It's all about capturing intent and using the right tool for the job. The moment in time case is pretty straightforward. The moment in a calendar case can get horribly complex because calendars are... very human constructs, and there are challenges capturing the entirety of human intent (did you mean for the position on the calendar to remain fixed even if the calendar changes? what about leap seconds? etc.), because often humans aren't even sure about their intent.
- karmakaze 2y agoYeah I was about to say the same, why make such a contrived example. A much simpler example is the case of iPhone alarms going off at the wrong time. A different real-world example that I like to give is when I was working at a photo sharing site that had global reach. We had a debate about how to store, convert, and/or display datetimes and I opted for local date/time. Ideally want to store both the local time and place of the photo which allows calculating every other time format. Even without the place, it still makes sense to show night time photos with their local time, and new years celebration photos at midnight.
- mytailorisrich 2y agoI always use TIA internally nowadays. Continuous, no leap seconds, no problems.
- globular-toast 2y agoHow do you synchronise to TAI? Does NTP support it?
- mytailorisrich 2y agoNTP provides UTC. UTC deviates from TAI by a number of whole seconds, the original offset plus all the leap seconds added since.
- globular-toast 2y agoSo you subtract the number of leap seconds from the UTC clock to get TAI? How do you update the number of leap seconds to subtract?
- mytailorisrich 2y agoYou never do this sort of conversion manually. On linux you can use clock_gettime() with CLOCK_TAI: CLOCK_TAI (since Linux 3.10; Linux-specific) A nonsettable system-wide clock derived from wall-clock time but ignoring leap seconds. This clock does not experience discontinuities and backwards jumps caused by NTP inserting leap seconds as CLOCK_REALTIME does. The acronym TAI refers to International Atomic Time. Now, leap seconds are advertised in advance and your system know when they occur through a leap seconds file (leap-seconds.list) that needs to be kept up to date.
- globular-toast 2y agoAh, thanks. I didn't think it sounded like something to do in application code.
- em500 2y agoThe short of it is that using UTC for events in the past is usually OK (you can at any moment recalculate the wall clock time in the past with UTC plus location data), but not for future events (e.g. scheduling, opening hours). Because the intent of stored future datetimes is almost always the wall clock time in the location where the event takes place. If TZ rules change for that location the intent is to pin the event to the local time rather than to UTC. For disambiguation, future events should ideally include location as well as datetime, though this is often omitted / implicit. The remaining edge cases are future events that span different time zones (e.g. scheduled calls with participants from different TZs). If one of the timezone rules chances, this can only really be resolved by rescheduling and updating the info for the participants.
- michaelt 2y agoHonestly, the moment your time handling library tries to address all the things a calendaring application could quite reasonably want to do, you're going to end up with an unsatisfying solution. After all, if I schedule a weekly recurring video call at 9:00 in City A, aka 14:00 in City B, then daylight savings starts in City A but not City B then either the meeting shifts to 13:00 in City B, or to 10:00 in City A. No amount of clever date representation can sidestep the fact that the meeting has moved by an hour for some attendees but not others.
- deleted 2y ago[deleted]
- can3p 2y agoI think the whole article can be generalized as following: one cannot make assumptions about relative values. You can replace UTC with US dollars and Amsterdam time with euros and talk about conference prices. If you convert 100 euro to US dollars at the time of record creation, the price at the day may not be 100 euros anymore. Ideally you record a tuple that allows to define value unambiguously (e.g. time 2022-02-21 9:00 timezone Europe/Amsterdam) because in this case you can always resolve the absolute time value later. This is a typical hiccup for any business expanding into multiple locations with different parameters (time zones, currencies, units etc). Once case that I find particularly interesting is an event that happens in different locations at the same logical (but different absolute time). Let's say you want to send an email to all your users across the global on Monday 9:00. If you want to add up to complexity, you could think about sending an email to all your users across the globe on the first working day next week.
- micheal0147 2y ago[dead]
- micheal0147 2y ago[dead]