Hacker News Reader

Comment by jarcoal | Hacker News Reader

Situations like Turkey's DST extension reminds me why storing dates in UTC with no further information is not good enough.

View on HN

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.

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.

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

> 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.

Time for governments to just make up their minds?

It is good enough. When converted to the local timezone, the library would know to offset the date properly - it just has to be told to do it. I don't see the problem.

Store the starting point for a meeting scheduled for October 30th, 2050, at 5pm local time in Pyongyang.

Are you sure the value of UTCunixtime("2050-10-30 17:00:00 Pyongyang") today will be correct in 2050? What if this record was created last year? (hint: the timezone was recently changed).

Remember, the meeting is supposed to happen at 17:00 local time on that day no matter what.

Ah, I understand better now. Though this wouldn't be a problem if timezone names weren't reused, right? eg. "2050-10-30 17:00:00 Pyongyang" would correspond to "2050-10-30 17:00:00 Pyongyang2" just fine.

Reply on news.ycombinator.com