4 ms·

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

by jarcoal 11y ago

mildweed 11y ago
Can you explain the complication you're thinking about? And what additional information you'd store?
- 0x0 11y ago
  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.
  - lucb1e 11y ago
    Time for governments to just make up their minds?
  - scrollaway 11y ago
    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.
    - 0x0 11y ago
      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.
      - scrollaway 11y ago
        > 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.
      - fanf2 11y ago
        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 http://fanf.livejournal.com/104586.html
scrollaway 11y ago
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.
- 0x0 11y ago
  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.
  - scrollaway 11y ago
    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.

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

by jarcoal 11y ago

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

mildweed 11y ago

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

0x0 11y ago
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.
- lucb1e 11y ago
  Time for governments to just make up their minds?
- scrollaway 11y ago
  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.
  - 0x0 11y ago
    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.
    - scrollaway 11y ago
      > 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.
    - fanf2 11y ago
      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 http://fanf.livejournal.com/104586.html

scrollaway 11y ago

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.

0x0 11y ago
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.
- scrollaway 11y ago
  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.