Hacker News Reader

Comment by taylodl | Hacker News Reader

In the U.S. falling back to standard time from daylight saving time is rough. Those days have 25 hours - and the interval from 1:00 - 2:00 repeats (you reach 2:00 and fallback to 1:00 and repeat the interval). Makes power scheduling difficult - which 1:00 - 2:00 interval are you talking about?

Also, the offsets between the timezones change. Eastern Daylight Time falls back from 2:00 to 1:00 Eastern Standard Time, which coincides with 1:00 for Central Daylight Time. So Eastern Time and Central Time are the same for one hour interval. Of course in the Spring you have the opposite problem - Central Time will be 2 hours behind Eastern Time for a one hour interval. So much for your interval time calculations! Also, the U.S. has changed the transition dates for the time change.

I'm so glad to be working on a system where I no longer have to worry about this crap!

View on HN

One of the interesting time-related applications I worked on was involved with medicines management. If a patient was to receive a medicine around the daylight savings change over we had to make sure it wasn't either doubled-up or missed completely.

I also worked on event planning software with plenty of timezone fun with events having a timezone, the planner a potentially different timezone and it also handled flights for speakers etc who could be coming from any number of other timezones. That was mostly straight forward with decent libraries, but it certainly taught me that you need to think in (and store) timezones and not just offsets.

During the last “fall back” event I experienced the 1 o’clock hour three times since I randomly happened to cross a time zone at exactly 2:00am…or maybe 1:00am?

The worst part was I had an appointment at 02:00, somewhere where they won’t let you in if you show up too early, in the other time zone and hadn’t had to deal with daylight savings time for a good long while having lived in Arizona where they don’t deal with such silliness. Trying to figure out what time to leave to time my arrival was very difficult.

> having lived in Arizona where they don’t deal with such silliness

Oh god, I'm simultaneously delighted at the idea of not having to deal with DST and terrified of writing software that might have to keep track of whether or not the user was in Arizona during a DST transition.

Arizona just stays on MST year long making it easy unless you have to figure out what time everyone else is on.

And for even more fun the Navajo Nation does do time zone changes.

Parts of Indiana have the same issue. Notice I said parts and not all - there are parts of Indiana that observe DST because they border with states observe DST and it's to their advantage to stay in the same time zone. What a mess! Just makes writing software that much more difficult!

That's why in the utility business it's common to use the language of standard time, daylight saving time, and prevailing time. For the Eastern timezone they write it as EST, EDT, EPT respectively. The important point is EST and EDT never vary - they'e fixed offset from UTC (UTC-05:00 and UTC-04:00, respectively). EPT is the squirrelly one - sometimes it matches EST and other times it matches EDT. At least when processing a time interval you know whether you have to take clock movement into account.

Reply on news.ycombinator.com