Hacker News Reader

Comment by webdevetc | Hacker News Reader

time zones change all the time. Most OS's automatically take these changes into account, I believe. ( see https://serverfault.com/questions/192858/updating-systems-ol... for a bit of info, but I think it is often included in OS updates rather than having to do it manually normally.)

https://en.wikipedia.org/wiki/Tz_database https://www.iana.org/time-zones

But of course there will be many legacy systems that assumes that all of Europe is on the same zone.

View on HN

At no point since the invention of timezones has Europe (the continent) been in a single timezone. Even if you only look at the EU, only time all of the EU was in the same timezone, was back in 1957 when "Belgium, France, Italy, Luxembourg, the Netherlands, and West Germany signed the Treaty of Rome, which created the European Economic Community (EEC)", and it wasn't even called EU. I would wonder which library makes that assumption.

Bad libraries that are written by people who think they don't need the tz.db to keep track of time, obviously.

Taking the change into account for the current time is relatively easy, but date/time libraries in programming languages need to be updated so that you can write a calendar application with, say, a recurring event spanning across the change, or count days since a specific date in the past.

Even with DST, the actual date DST starts differs unpredictably from year to year. I don't think this introduces any new problems.

In the EU, the start date is predictable: the last Sunday in March. The end is equally predictable: the last Sunday in October.

Interesting.

I suppose that consistency could’ve given some EU only companies enough rope to hang themselves. Really, doing things the right way is easier than hand-writing some code that assumes DST starts/ends on a fixed date—at least in a language with a real date/time library.

Reply on news.ycombinator.com