Hacker News Reader

Comment by mildweed | Hacker News Reader

Can you explain the complication you're thinking about? And what additional information you'd store?

Lots of events needs to be scheduled in local time. If your calendar app stores a given UTC timestamp for your meeting with a customer on friday at 5PM and the time zone rules database change inbetween, you're going to have an angry customer.

Time for governments to just make up their minds?

And what would meta-metadata about the datetime solve? What you're looking for is faster updates to timezone libraries. And for governments to stop being idiots — "I'm delaying DST because it inconveniences me", pah, what a load of garbage. It's a symptom of how much DST sucks. If anything, this couldve been a good occasion to repel DST in turkey.

If you stored it in the DB as "2015-10-30 17:00:00 SOMETIMEZONE" then it would be unambiguous when the event is going to happen. If you stored an UTC timestamp, well, then you'd get two different values depending on whether you had the updated tzdata or not when the value was entered and converted to a timestamp.

If you think this problem can be solved by declaring today's version of tzdata immutable and final, then I'm afraid you're not being realistic. Timezones, DST rules, country borders will change and always have.

> by declaring today's version of tzdata immutable and final

It doesn't have to be immutable and final, it can simply be versioned then :) cf what I said in my other reply, if you create a new timezone every time you change it, it seems you don't have that problem.

Storing the timezone name does not work when the boundaries between timezones change. Best to store local time and location. http://fanf.livejournal.com/104586.html

Reply on news.ycombinator.com