Hacker News Reader

Comment by abfan1127 | Hacker News Reader

It seems that the example provided is a poor example. Software systems compute based on some rules. If you change the rules, you must change the software. Are there other more meaningful examples?

View on HN

Author here. When the timezone rules change, the software updates its timezone database. This is how it should be. You don't have to change the software, the software should be able to handle the changes to the timezone database.

The updates are available here: http://www.iana.org/time-zones So far there has been two new releases of the database in 2015. Last year there were about 10 changes.

sorry, thats what I meant by the software (change its ability to understand the rules). IANA link is helpful!

The example is a good one, you are just misunderstanding what the problem is. Here is the synopsis:

1. User makes an appointment for 11am local time when he meets his friend in Chile. Using current timezone rules (GMT-3), the program saves this in the database as 1400 UTC. 2. Chile decides to change the rules for their time zone. Software gets updated with new table. Now, the appointment is at 10am local time in Chile, since they are GMT-4 now (1400 UTC = 10am GMT-4)

The example is perfect. It isn't enough to change the software, you must also change the existing data, because with the rule change it is now wrong. Or you can take the advice and store your data in a form that doesn't become obsolete when the rules change.

If you store it in UTC, it becomes obsolete when the rules change for that location. If you store it in the local time, it becomes obsolete for other timezones (think the timezone of the traveler before they leave). If you store both UTC and the local, then one (of the 2) becomes obsolete, but recoverable assuming you can scrub the data. However, you must know which is correct based on the rules change itself.

Reply on news.ycombinator.com