6 ms·

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

by mildweed 11y ago

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

6 ms·

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

by 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