Hacker News Reader

Comment by jakejake | Hacker News Reader

Before clicking the link and knowing absolutely nothing about what project this even is, I knew from the headline that it would be a timezone or DST issue. I've had the displeasure of dealing with a lot of TZ offset issues in a time-critical app. They are a always a joy to discover, fix and test.

View on HN

I was also thinking this would be related to DST. The "tricky" bit about Australia is that DST is "backwards", at least compared to those of us in the northern hemisphere. Because the seasons are reversed from those north of the equator, DST is also likewise reversed. They spring forward in October, and fall back in April. It all should make sense when you think about it. (Longer days are still in the summer, and thus DST is still in the summer.) This is of course not unique to Australia. (I think they just happen to crop up probabilistically by having a high population using technology, and are south of the equator.)

The cool bit, at least to me, is that the mnemonic "spring forward" still works. Likely, this is only cool to me because the whole thing is unusual.

The other odd bit is that some TZs sit on the "wrong" side of the international date line, and thus get interesting offsets such as +13 or +14h from UTC. I think there's some that are -13h too, so the total "length" of day (that is, how long you could remain on a calendar date) is >48h. Thus, at any given time, people in their local time are in as many as three different calendar dates.

There's also a few TZs with half-hour offsets. (e.g., they're something like 4.5 hours off UTC.) There's a 3-hour TZ jump at one point on China's border, I think, because all of China is on a single timezone, and the nation is quite wide, east-to-west.

We've not even gotten to leap seconds, or that 2100 won't be a leap year.

And governments regularly muck with this stuff. The set of timezones and their offsets and DST preferences are constantly changing.

When speaking about general false assumptions about timezones, this article tries to capture as many as possible: http://infiniteundo.com/post/25509354022/more-falsehoods-pro...

I have mixed feelings about that article.

To get anything done, I feel like the general programmer[1] is allowed to assume, at a bare minimum, a Proleptic Gregorian calendar. Anything else just makes handling early (pre-Gregorian) dates madness. (Various geographical locations adopted the calendar at different times, so you end up needing to know where you are to compute the "local" date. Even further back in history the rules get even more odd, and unknown. [2], if I read it correctly, includes a table of when scholars _think_ people inserted leap years.)

Once you go with "Proleptic Gregorian calendar", I think points such as

> Months have either 28, 29, 30, or 31 days.

…are actually always true. Of course, two bullets down is,

> There is only one calendar system in use at one time.

Which is essentially what we're using as axiom here. It's true because we've defined it as such. (Cheating, I admit, but if you're building the next great mobile app, do you care?)

I do wish that site included fold-out sections to de-mystify some of the points.

> Non leap years will never contain a leap day.

Your definition of leap year isn't "year with a leap day"?

> Unix time is the number of seconds since Jan 1st 1970.

> Unix time […] is […] defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds.[3]

Again I wish for pop-out explanations, because I'm left to wonder whether POSIX's lack of leap seconds is what the author is hinting at.

I'm bored though, so perhaps I should write a gist showing which of these I believe to hold (and why) and which do not (and why).

[1]: I think anyone breaking this rule would know that their area of interest requires them to break it, and thus know that they need attention.

[2]: https://en.wikipedia.org/wiki/Julian_calendar#Leap_year_erro...

[3]: https://en.wikipedia.org/wiki/Unix_time

Agree with everything you've said, but keep in mind non-Proleptic can still be found. Java splits on 15 Oct 1582 by default:

https://docs.oracle.com/javase/7/docs/api/java/util/Gregoria...

What about the Islamic calendar? If your software handles anything having to do with dates and is being used internationally then it seems to me you have to take that one into account: eventually somebody will want to see their calender or input a date in their local date handling system.

Edit: I am confused about the downvotes. I point out that he can't assume there is only one calendar system in use, even for general software.

I guess you're being downvoted because your point about Islamic calendars is (mostly) wrong. Islamic calendars (but I don't even live in a country where it's used, so it might be more nuanced than what I say) are used mostly for religious purposes; you 'can't' (practically speaking) use only the Islamic calendar because many things you care about (like, your barber's appointment) would be done in 'Gregorian calendar'. So an Islamic calendar is only needed in a very limited subset of all software packages, even in Islamic regions. It's not as simple as 'in some areas people use Gregorian, on others Islamic', which your post seems to suggest.

Iran is using the Islamic calender. Just look at their railways website http://www.rai.ir/index.aspx Or the website for the airport in Tehran ( http://ikia.airport.ir/ ), which uses persian dates for the weather forcase and gregorian for flight details.

Thai Railways is using the Buddhist calendar http://www.railway.co.th/home/

And yet, when I am contacted by Iranian researchers, they all express dates and times in the Gregorian calendar. Obviously those with international contacts are not 'average', but still there is/must be wide spread use of the gregorian calendar - as your airport example confirms.

Either way, let's still for the sake of the argument say that all of Iran only uses the Islamic calendar. That still reduces the GP's point from 'to sell software in countries that are mostly Islamic, you must support multiple calendars' to 'to sell software to Iranian customers you must support multiple calendars'. Iran, just to state the obvious, is widely embargoed across the world, and it's quite challenging to sell anything there, legally (I have first hand experience to the extent that it wasn't worth the time for 5 figure contracts - and I suspect that even 6 figures wouldn't make it worth it).

To conclude, I don't think your contra-anecdotes are enough to counter the position that assuming Gregorian is 'good enough' in the vast majority of cases (again, those few writing software for Mormon record keeping, or history journal analysis tools, or -yes- software for Iranian state systems, probably know so much about dates and times that they don't need '100 things' lists to know what to look out for).

I bet they're also writing in English, but that doesn't mean you can just use 7 bit ascii for everything everywhere.

That addresses (well, tries to apply a false analogy to) the first paragraph of my post, the least significant of the three.

> There is only one calendar system in use at one time.

This is useful, but technically false. Go tour graveyards around Boston. You'll find stones with two death dates on them from the mid-1700's (most of the US changed in 1752).

Non-gregorian calendars are in use today. e.g. the website for Thai Railways ( http://www.railway.co.th/home/ ) uses the year 2558

There's even a silly bit of Australia that has a TZ on a 45-minute boundary (UTC+8:45). Eucla is a tiny place in the middle of nowhere, population 86 in the town, though I don't know how many others might be in that TZ.

http://en.wikipedia.org/wiki/Eucla,_Western_Australia#Time_z...

There's also the more well-known Central timezone, which aligns on a 30-minute boundary.

Nepal is the canonical :45 offset timezone example (UTC+5:45, ~28 million people).

I think the Sillier one is Broken Hill. That although its in NSW is on the SA Timezone.

Well that makes sense in the real-world; Broken Hill gets South Australian television and radio and is much closer to Adelaide than Sydney (500km to 1200km), it makes sense to be on ACST not AEST

Kununurra have the opposite problem - they are on AWST but are only about 400 kms from Darwin. So the sun comes up at 4am and sets at 4pm.

Border Village, a roadhouse on the other side of the WA/SA border, also observes Central Western Time Zone. However, the next stop on the Eyre Highway does not.

If I recall correctly from the last time I had to deal with this, it's the first 3 towns on the Eyre highway in WA coming from the SA border. This[1] suggests there are actually 4.

[1]: http://www.postcodes-australia.com/timezones

Brazil is another fun one that has caused my team's systems to blow up: since their DST transition occurs at midnight, there is no midnight on the DST transition day.

Brazil is the most populous, which is why you've blown up there. They are actually one of a group of ten locales that transition at midnight. They have the dubious distinction of making the JS Date object revert back to the previous day if you create a Date with the transition day due to the constructor defaulting to midnight if not specified. (e.g. new Date(2013, 9, 19) in Brazil) The rest of the locales are much smaller and less likely to have customers you will break: Brazil, Chile, Paraguay, Cuba, Greenland, Iran, Lebanon, Syria, West Bank, Gaza Strip.

As a dev living in one of those half-hour offsets (ACST +9.5 Adelaide, South Australia) i think the only thing it's changed is our awareness of timezone issues, although there's discussion about moving us into AEST or back to AWST which … well … will be painful

Not as much of a joy as when an upstream dev is snottily reverting fixes for a commercially-supported open source product because they refuse to believe in the TZ the customer is in exists.

I am currently working on an application which just uses offset numbers to tell how far away from Greenwich time the zone is. No daylight savings time offset, no south of the equator, etc. Just a hard coded number for each client.

Reply on news.ycombinator.com