Dang, I was hoping this article would be about a company whose work hours were set so that the absolute time didn't change throughout the year (e.g. 8-4 in the winter and 9-5 in the summer).
Instead, we get a very different, very interesting tale. Reminds me of TheDailyWTF.
If the absolute time never changed, people’s sunlight modulated circadian rhythms would be all
messed up, which is unhealthy. Best to rise with the sun.
In that case, people would constantly be changing their work start time throughout the year, perhaps monthly, but if they really wanted to be pedantic about it, by a minute or so each day.
That seems... silly? DST shifts seem worse for our health than just working our regular hours without time changes.
Between May and July, many cities in the northern hemisphere technically have no astronomical "night". But you made the wish, the monkey-paw curled a finger, and now all of Canada and Northern Europe are living in the Sleep Experiment timeline.
Now this is an idea I can get behind. Getting to sleep in until nearly 9am sounds great to me. However, if it is summertime, we'll have to disagree since I'd have to technically not sleep under your plan.
We didn't do DST at reddit. Or more specifically, I set all the servers to Arizona time. Since we were all based in Pacific time, 8 months of the year our clocks matched and the other 4 we could just subtract one in our heads if it mattered. But as a benefit we didn't have any strange gaps in logs and code didn't have to deal with time changes.
You apply your local timezone to the UTC value. There is no reason to store a timezone with it.
The weird thing is you need to always apply the timezone when reading, and un-apply it when writing. This needs to happen at the lowest level of access.
I know how you can convert UTC to local time. The problem is that without timezone info, some system can parse the UTC time AS local time. There is no reason for most date parsing libraries to assume that they are always being fed UTC times and from what I've seen, most date parsing libraries assume timestamps without timezones are in local time unless told otherwise. You can avoid all of this by always storing and passing around timestamps with timezones.
Don't use that for future appointment times though. When someone books a 9am appointment in 6 months they want that at 9am of whatever timezone it will be at that time and location.
Don't use it for past times either without thinking what you'll use it for. If you want to generate reports of historical data in the user's timezone at the time of the event, you can't convert back just knowing their current timezone. [0]
I find UTC painful from a West Coast perspective, too. -8 is 1/3 of a day, and it puts the UTC date rollover at either 4pm or 5pm depending on DST. It genuinely makes solving problems using logs twice as difficult, as a lot of problems strangely tend to happen around that time.
I've been reading UTC times from all over the world for 20 years ... I've never had any issues. You only have to convert once: the time of the incident.
When you work on a consumer app, it's often important to correlate incident events to real clock time, especially if an external event caused the incident. It's much easier when your logs match your clock.
Speaking from my 30 years of experience reading logs. :)
> especially if an external event caused the incident
this has a trivial solution - you convert the times of external events to UTC as well.
for example, the Super Bowl is going to cause a spike in traffic. the Super Bowl this year had its kickoff at 23:30 UTC.
> It's much easier when your logs match your clock.
part of the point of UTC is that "your clock" shouldn't be viewed as privileged or universal. because other people have different clocks.
what you're doing with this Arizona trick is basically inventing "UTC, but slightly different and more convenient for me specifically"
you get used to doing this "they usually match, except 4 months of the year they're off-by-one" trick. but then you're on a business trip to New York, and now you have to remember that it's either a 2 or 3 hour difference, depending on the time of year.
or, you hire a remote engineer in Adelaide, which is UTC+9:30 or UTC+10:30 depending on DST. do you want that engineer to be doing half-hour addition & subtraction in their head in order to correlate log timestamps in Arizona time with their local clock? also keep in mind they're in the southern hemisphere, so they have "summer time" reversed from the northern hemisphere, and they do 6 months on and 6 months off instead of 8 and 4 as the US does [0].
every desktop environment I know of supports adding a second clock with a different timezone to the system tray. on my work machines I have one for my local time, and one for UTC. it's very easy to look at the latter when I want to know "what's the current time as far as my servers are concerned".
I am a strong believer in not storing logs, as they tend not to be useful after a few minutes, other than security logs. But I do find real time logs to be useful information for incident response.
> your computer’s internal clock doesn’t actually go forward or back one hour
Kind of, there's multiple "internal clock"s. Windows (in)famously uses localtime instead of UTC by default for the RTC (stored in CMOS) which has caused many bugs (would list them all but my old bookmarks to MS KB pages were all broken by MS's site redesign), and setting the (unsupported) HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal registry key causes yet more bugs.
A hilarious one was Windows getting stuck in a loop continuously changing the time back to 01:00 every time it reached 02:00 because it couldn't persist the "InDST" flag.
In a different life I did some freelancing, and worked on an app that had a really bad outage at midnight local time on a seemingly arbitrary Thursday. The first HTTP request that arrived to the company front page after midnight crashed. Every subsequent HTTP request did the same.
A friend took the call, and started tracing logs.
A strange problem came into focus - requests to the company front page were crashing in a subroutine for scheduling the weekly bulk FTP upload of materials to a paper printing shop - thousands of pamphlets and books the company would order to be printed each Thursday.
It turned out that the way the scheduling worked was: Each HTTP request to the company's website would check "is it thursday?" and "if yes, are there any files in the print shops FTP server?". If you were the unlucky browser that happened to answer yes to both, your latency to load the website was very high, as it also included the very large FTP upload.
Anyway. The routine that checked if todays date was a thursday worked by comparing the current date to a hand-written list of thursdays. The prior week had been the last thursday the hacker that wrote the FTP upload job had added to the list.
This is how you should store time https://cr.yp.to/libtai/tai64.html .
Many events also have a "where" associated with them, you should store that too.
By storing where and when, you can derive lots of other things that are usually conflated with the first two. Like where the sun was in the sky, the direction of the prevailing winds, outside temperature, and whether the local jurisdiction plays games with their clocks twice a year.
I pride myself on being flexible and adaptable. I’m good at what I do, but there are so many things I don’t know yet and I have to trust the smart people around me to make those decisions.
But there are times I see it as my job to dig in my heels and say oh hell no, we’re not doing that. This would be on that short list.
time handling is rough, but a rule of thumb is to use absolute time (e.g. UTC timestamps, datetime with tz offset) for things that represent a concrete point in time (especially if they've already happened) and use time in a timezone (not an offset) to represent future events. In this case you'd store 9AM on this date, in this timezone, then lookup the absolute offset closer to when you need it.
That technically doesn't work; you have to store the location, not the time zone. Standard time and DST are actually two different time zones (and are represented as such in software); if you were doing your scheduling in January, and said "9am on July 8th in the current time zone", then the event would get translated to the wrong time when July arrives (because "current time zone" in January is standard time, while in July it'd be DST).
If you instead just specify a location, then the hour number for the time always remains the same, and the time zone gets inferred from the location.
This also saves you from the possibility that DST rules might change for that location in the future, or that there might be a more major reshuffle, and the location gets moved to an entirely new time zone. (Like, for example, say the Chinese central government decides to stop being shitty to most of their country and allows the central and western areas of the country to be on a different time zone from Beijing.)
I don't think future vs past is a good distinction. There is really not a succinct rule of thumb (the common one, "just use UTC", can mean multiple things and can mislead juniors), which is a symptom of the conceptual complexity of distinguishing time as a physical measure vs time as a cultural construct.
This is compounded severely by the insistence of many languages, libraries, and platforms of calling absolute times "Dates" and reinforcing that lie by silently picking arbitrary tz offsets to add to your absolute times at API edges - perhaps the single most destructive cutesy convenience in the history of software.
The only real rule of thumb is: If the clock time, calendar date, or tz offset matter in your use case, store them. Otherwise, use absolute time. Learn how your platform stores time and then you will see where your tools are doing the conversion for you, and STOP them from doing it.
I worked for a streaming platform some 15 years ago. They would charge users by the second for watching live content. Shortly after I joined, DST kicked in, and I was surprised to learn that they simply shut down the whole website for one hour twice a year. They seemed to think this was easier to deal with than fixing their (many) time handling bugs ...
This is one of the easier things to handle in date time code. Take a localized date and time from the user, convert to utc, store that in one db field and the offset in another. It gets even easier if the TZ is a form option for an entity above the data being stored. To read you grab the utc date time, add the offset, grab the current time, convert to utc, add the offset, then do the comparison. That’s not much work for 100ks, a bit of work for millions, and a lot of work for billions. So real time must stay in the 100ks area, otherwise, do it in a background process and accept the cost. If you really need it, convert dates to big integers and do simple math. But check whether it makes a half order of magnitude difference in proc time. If not, move on.
I have a meeting every Tuesday at 10AM in New York.
How do you store that? Given that it's sometimes going to be 1500UTC, sometimes 1400UTC, and in the future it could even be something else, and the date when it changes from EST to EDT in New York Can and Has changed.
Well, since you specified a recurring meeting ... you have to "actualize" the meeting for some distance into the future. So, you'd create a whole bunch of meetings in that timezone, on that date, then convert it to UTC. Sure, some will be 15:00, some will be 14:00, but that doesn't matter if you stay in the NY timezone.
But if you fly out to Amsterdam, it's really important that the time can and does reflect your current timezone ... or you're going to open zoom at exactly the wrong time. Even more fun is that EU DST is a different date than US DST.
I've used a database layout that mirrored the data that can be in an ical file, which supports defining the recurrence without having to actual create each instance, and supports recurrences with no end date.
We went with something similar to that at one point. Our problem was we had only a few dozen ms to render thousands of recurring events. Most customers didn’t look more than a few weeks ahead (though we rendered them out decades). Using your approach would have taken too long to calculate intersections — it was our initial approach actually — but just making a simple query and rendering actual events was much faster.
Because you are creating times for events you don't know what the UTC will be. if you are lucky your guesses will be right.
If you created an event in 2004 for 10AM New York in 2008, you may well have created it for 1500 UTC based on predicted time in 2008. When the Energy Policy Act of 2005 passed that event would have had to change to 1400 UTC. As you didn't store the timezone you had no idea whether to change it or not.
Chances are your users just ignored the problem, blamed the government rather than your poor code, or you didn't exist then, and you as an american-centric company has no idea that unpredicted unscheduled DST time changes occur all the time.
> Because you are creating times for events you don't know what the UTC will be.
This is what settings are for. This was an enterprise application, so the timezone was set for the location of the venue, in the settings. We knew exactly what timezone to convert from/to.
> if you are lucky your guesses will be right.
This is software, there is never a reason to guess.
tzdata makes guesses (predictions) all the time -- every time in the future is a guess. There is no way to know that a government won't change DST dates, or even shift a country to a different timezone.
Look at the whole Lebanon mess from earlier this year:
If you had, at Mar 24 2023 10:00 UTC gone and created a meeting at 10AM Beirut on Mar 27th 2023 it would have been at 0800 UTC (based on the official Lebanon position that DST would not start until April 21st [0]), and you would have been wrong [1]
Had you stored the datetime with location then you would have been fine.
The tzdata community far know more about time than you do and make a good job at guessing what the time will be, but they still have to issue multiple updates each year due to changes from different governments.
Take this update from 2021 when Fiji suspended DST for the following year
It's a guess. nobody in October 2021 could say for certain that Fiji would or would not have DST in 2023.
This isn't controversial. Past dates can be problematic - especially from 50+ years ago (historical data may crop up which shows that a specific location had different UTC offset which means a historical update is needed), but for future dates all predictions of UTC offsets for geographic locations are a guess [2]. Hell you can't even store the tzdata location group (say Europe/London) because in the future Scotland could decide to keep DST but England/Wales/NI/Ireland could move to BST year round. In that situation meeting at 10AM Edinburgh stored as 10AM Europe/London would be at the wrong time. That's more rare than DST date shifts, but it still happens
What happens when New York stops following DST? Half of your precalculated events are now wrong. You could recalculate them but now you have to have logic for figuring out when to do that.
Much better solution is to store the repeating event, and each event time, in the originating time zone. Then calculate other time zones from that, which is a little more complicated but doable.
That’s a business problem no? Because any events with attendees in other timezones are going to be different now too. So it boils down to customer communication and business decisions. Both are valid.
The business decision is that the event occurs at 10 AM local time in New York on April 29th 2026, not that it occurs at XX:00 GMT.
There is no way to know whether New York will be in DST or not then. Timezone changes can be made with just a couple of days notice, and sometimes not even clear even once they've happened (or not happened)
Yeah, that might be your business's decision, but every business will make different decisions. No matter what, if a timezone changes like that, you've got issues since you need to update the TZ database in the servers.
- you can shift the time to the new timezone if it is stored in UTC (this is effectively the same as storing them in local time). You still have impacted users to email.
- you can leave it unshifted. You still have impacted users to email.
No matter what, you have to communicate with users. The difference comes down to how much work you want to do and how much coordination you have.
> - you can shift the time to the new timezone if it is stored in UTC (this is effectively the same as storing them in local time).
No you can't, as you don't know if the time was New York, or London, or Morocco
> You still have impacted users to email.
Why, nothing has changed.
Your decision to ignore the users wants (I want an event as 10AM in new york) and replace it with your wants (I want to store time in UTC for some reason). That's wrong.
> No you can't, as you don't know if the time was New York, or London, or Morocco
Hmm. I'm not sure what you mean? Users in these kinds of applications specify their timezone somewhere. It usually isn't enough to rely on browsers for this kind of setting. For example, when you travel to a different timezone in Google Calendar, it warns you that your setting doesn't match your current timezone of your calendar, but the timezone setting is independent of your browser.
> Why, nothing has changed.
I don't think you're thinking of the knock-on effects of a random political change to a timezone in a calendar-ish application. If NY were to suddenly disable DST -- and for illustration purposes, let us assume they disable it DURING DST -- even if you store it in the (self-proclaimed) "correct" local time, people who are attending one of your events from a different timezone will observe your event shifting by an hour. Any event from someone else's calendar in another timezone will likewise be observed as shifting one hour. Thus, as a business, you must communicate to these affected users that they need to be aware, after all, someone a world away from the NY timezone is unlikely to be aware of the political ongoings of NY.
But this is an extreme case, right? Surely we'll get some kind of heads-up? It doesn't change the effect, it just delays it. Even if we store them in UTC, we can simulate the same effect by manually shifting people's calendars in that timezone with a single query.
> Your decision to ignore the users wants (I want an event as 10AM in new york) and replace it with your wants (I want to store time in UTC for some reason). That's wrong.
That's your opinion and ignores a whole host of potential other reasons to store it in UTC vs. local time, and none of it has anything to do with users, but business requirements in order to perform something more powerful and valuable than storing time.
If your alarm is set to go off at 7AM London time on Dec 1st, and the UK government decides to shift the UK to UTC+5 for some reason, the alarm still needs to go off at 7AM London time, but it's changed from 0700UTC to 0200UTC.
There is no need to inform the user of a change if you have stored the date correctly -- as 7AM London time.
If you had stored the alarm at 0700UTC, you are wrong. You may be lucky and the government doesn't change the time, but just because you are lucky it doesn't mean you are right.
If your user wants to store a date in UTC, that's fine, that's their choice. If they want to store it as London time, that's also fine.
None of this matters if it only affects a single person/organization. It doesn't matter what time zone you are in, it will "just work," the only thing that is different is the amount of effort required by the dev. Even then, there's probably going to be a delay while tzdata is updated downstream and on the servers/phones/etc.
It only matters when you have people in multiple timezones. A better analogy would be if you set an alarm to go off 7AM London time, for me, and I am in Amsterdam time.
When the UK decides to switch to UTC+5, that 8 AM alarm (CEST) won't go off ... instead it will go off at 13:00 CEST. That is why you need to notify users that have an appointment in a different, affected, timezone.
That doesn't work for recurring events. If you want the meeting to always happen at 09:00 in New York, you have to store the time and the "America/New York" time zone, then for each recurrence you translate to local time for each user/participant.
The entire Midwest Energy Market (MISO) does not use DST, but not by disabling it but by setting their org's timezone to EST.
On one hand this simplifies a lot – days are always 24 hours for example.
But it does complicate interop outside of the market since energy is traded with DST based markets, and gas is bought using the gas day clock (also DST). The gas day starts at 10am eastern prevailing time, eg. 9am is yesterday, 10am is today.
The sun does, to an extent: at the height of summer it never sets and at the low of winter it never rises (kinda, technically in Akureyri you do get 3h of daylight or half an hour of twilight at worst, and Reykjavik has a more forgiving 4h of daylight and 3 hours of twilight, no actual night from early april to early september tho)
Instead, we get a very different, very interesting tale. Reminds me of TheDailyWTF.