▲ 67 points
back
73 comments
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.
> Best to rise with the sun.
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.
Apply that to the nordic countries, and you’ll not have a fun time¹. Some days you won’t even get out of bed, others you’ll never go to sleep.
¹ Or it might be extremely fun—for a while—depending on your personality.
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.
> strange gaps in logs and code didn't have to deal with time changes.
Use UTC for everything, except when displaying then convert at the last moment in UI code
The U in UTC is for Universal.
Except if you don't include time zone info with your timestamps, even with UTC, some system will inevitably interpret it as local time.
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.
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 don’t like UTC because I don’t like doing -8 in my head. In Arizona time I can read raw logs easily.
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.
Which Arizona time? ;)
The one that doesn't change. :). And FWIW the one that does change is called Navajo time.
> 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.
> Windows (in)famously uses localtime instead of UTC by default for the RTC (stored in CMOS)
Probably because historically users could/would set the time in the BIOS setup and would use local time.
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.
TAI doesn’t have leap seconds, and would thus also not have the apocalyptic DST-like effects of a negative leap second.
Just a little more than a decade and the leap second madness will stop.
I was shocked by this... and here I thought I'd seen enough incompetent processing of datetimes that nothing could surprise me.
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.)
timezones as in IANA tzdb[0], not offsets from UTC. The terminology is confusing.
[0] https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
But whatever you do don't assume the location must be the user's current location.
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 have meetings in us-eastern, Irish time, and Indonesian/se Asia time, scheduled on the same calendar, and somewhat intertwined.
2 do DST. And they change on different weeks. One is a half hour time zone and doesn’t do DST.
UTC plus time zones isn’t enough for recurring meetings.
I’m forgot to mention, set TZ to GMT on the servers so your languages function calls get UTC be default.
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.
Daylight Saving Time (DST)
We should all just move to Iceland where, being sensible, they just use UTC+0
You can just set your servers to UTC. Although if you're not in europe correlating to local time is a bit of a pain.
why cant we adopt the same standard (along with metric)
There's "Swatch Internet Time" (.beats), they're a form of metric time :)
It's not really all that sensible. Considering Iceland's longitude UTC-01:00 would be their sensible timezone.
Nothing prevents Icelanders from getting up at the time that maximises sunlight for them.