Hacker News Reader

Comment by raxxorrax | Hacker News Reader

I have written code that only works in winter because of daylight saving times and some unfortunate date conversions, but having a temporary correct syntax is really a new high.

View on HN

As a part of a release always got borked, I wrote a small bash script that took currently deployed files, archived them to rollback_dateandtime.tgz, then put the freshly released files in its place.

It turns out we never did a release before 10:00, because it ran fine for a few years, but the regex constructing the filename could not deal with hours consisting of 1 number.

Oh well, never write production shell scripts while your platform is burning.

The fix is literally 1 character, but I only get access when production burns. So I was not allowed to change it and the owner does not want to implement it and file all release paperwork it entails. Instead, mgmt forbid this type of release before 10:00.

This is why we can't have nice things.

I have written code (at work) that crashes when the moon is in a specific phase.

I had a "switch(moon_phase)" and forgot one of the cases... And the Android app was in debug mode, so any uncaught exception brought the whole thing down.

Not nearly as cursed as two parent comments, but there was a widespread problem in my very popular Android app. The relative date formatting function worked incorrectly for many users, it was off by one hour. It turns out that when Russia (where most of our users were) had abolished DST, and then changed timezones a couple of times, people got really confused. Since Android's timezone data is part of the system, it was basically set in stone. Most of the users didn't choose the timezone with the correct offset, but instead set their time an hour forward so the incorrect timezone and incorrect unixtime cancel each other out for a "correct" displayed time.

I ended up getting the known correct unixtime from the server to try to guess which timezone offset the user actually meant and correcting the result of System.currentTimeMillis() and my formatting for that.

Having the code crash every full moon would be pretty cursed tbh.

I have once heard of some software that would crash on some Wednesdays. Apparently Wednesday is the longest day name, and it was overflowing some buffer. But only if the day of the month was 10 or above, because the strings 1-9 still fit in the buffer.

> I have written code that only works in winter because of daylight saving times and some unfortunate date conversions

Not sure where you are located, but this can be particularly bad in the UK where winter time happens to coincide with UTC.

Yeah it’s horrible. I had a contract a number of years ago to fix a bug that they had been fighting for 5 years. When winter time kicked in all appointments on their booking system collapsed to zero minutes long.

To fix this they ran a SQL script that changed the end date on the DST switch over but that had some poor assumptions in it and made it worse.

It also had to be correct in the past and the future.

I just rewrote the whole fucking thing from scratch.

Let's be pedantic about this, because this is one of the very few areas where pedantry matters: GMT ("British Winter Time") is NOT UTC, and it can differ from UTC up to 0.9 seconds. GMT is a time zone (corresponding to UT1). UTC is a time standard.

To be pedantic, this is an area where pedantry occasionally matters. For the vast majority of (casual) usage, it doesn't.

Indeed. I get invites from people from the UK who simply refer to the current local time (GMT or BST) as "GMT". It just means current London time to them.

Same happens in the US, people use EST/EDT interchangeably (and incorrectly) when they mean Eastern timezone. Or Central/Mountain/Pacific.

I appreciate your pedantry, and I wonder if you know of a widely used computer system which genuinely implements the GMT time zone as something different from UTC+0.

There may be some niche astronomical or legal(?) applications which have to keep track of the potential 0.9 seconds skew, but my impression is that any app which claims to support a "GMT" (or Europe/London) option is actually only supporting "GMT-ish".

Ok, fair enough. But it's close enough that it's very easy for anything that isn't working with second-level granularity to seem like they're working only to break as soon as the time switches BST.

> GMT is a time zone (corresponding to UT1)

Are you sure? Looking into things I would have said that GMT exists as a time reference but all the time zones are based on UTC.

The first iPhone app I wrote back in college would crash if you used it in a time zone with a positive UTC offset. I can't even remember why.

Reply on news.ycombinator.com