We don't do DST at this company

Dang, I was hoping this article would be about a company whose work hours were set so that the absolute time didn&#x27;t change throughout the year (e.g. 8-4 in the winter and 9-5 in the summer).<p>Instead, we get a very different, very interesting tale. Reminds me of TheDailyWTF.

We didn&#x27;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&#x27;t have any strange gaps in logs and code didn&#x27;t have to deal with time changes.

&gt; your computer’s internal clock doesn’t actually go forward or back one hour<p>Kind of, there&#x27;s multiple &quot;internal clock&quot;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&#x27;s site redesign), and setting the (unsupported) HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal registry key causes yet more bugs.<p>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&#x27;t persist the &quot;InDST&quot; 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.<p>A friend took the call, and started tracing logs.<p>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.<p>It turned out that the way the scheduling worked was: Each HTTP request to the company&#x27;s website would check &quot;is it thursday?&quot; and &quot;if yes, are there any files in the print shops FTP server?&quot;. 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.<p>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 <a href="https:&#x2F;&#x2F;cr.yp.to&#x2F;libtai&#x2F;tai64.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;cr.yp.to&#x2F;libtai&#x2F;tai64.html</a> . Many events also have a &quot;where&quot; associated with them, you should store that too.<p>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 was shocked by this... and here I thought I&#x27;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.<p>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&#x27;ve already happened) and use time in a timezone (not an offset) to represent future events. In this case you&#x27;d store 9AM on this date, in this timezone, then lookup the absolute offset closer to when you need 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.

The entire Midwest Energy Market (MISO) does not use DST, but not by disabling it but by setting their org&#x27;s timezone to EST.<p>On one hand this simplifies a lot – days are always 24 hours for example.<p>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