5 ms·

I have found that no matter what language/platform I use, the one thing that is always supported is UNIX timestamp. That makes date+time operations much easier:

• masklinn 10y ago
  Except (2) doesn't necessarily work when events are local and you factor in timezone variations (both DST and actual TZ changes). There are classes of events where you're much better off with zoned local dates e.g. local meetings. Example: in early 2011, Samoa announced that on December 29th at midnight local they would switch their timezone offset from -11 to +13. Before that announcement (or at least before your timezone database has been updated), store as UTC a meeting in local Samoa time, and the user will miss their meeting by a day. Of course storing a meeting on December 30th local would also have been fraught as there is no December 30th 2011 in Pacific/Apia but that is a common occurrence historically due to the unsynchronised julian/gregorian switches e.g. none of the dates between February 16th and February 28th 1923 (included) exist in Greece, and the US doesn't have a 9/11 in 1752.
  • appleflaxen 10y ago
    I think the recommendation still holds. You want a meeting at 1100 local time. Meeting is stored for that time in UTC, on the correct date (before Samoa changed, we all understood what date you meant) Samoa changes the rules. The calendar doesn't change. This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify.
    • achamayou 10y ago
      Classic counter example: storing business hours. If the store/exchange opens at 8:00AM every weekday in Somethingania/Foocity, you want to store 8:00 and the name/reference of the timezone. Because the store/exchange will still open at 8:00AM local time, even across DST, government-mandated timezone changes etc (largely, I'm sure there are exceptions but for stock exchanges there definitely aren't). School times, times for religious services, lots of times are relative to local time, which itself is subject to change against UTC (sometimes predictable, sometimes not, the government gets to update the timezone and the DST scheme arbitrarily). So only ever storing UTC and using local time purely for display isn't a sustainable one-size-fits-all option.
      • deleted 10y ago
        [deleted]
    • masklinn 10y ago
      > You want a meeting at 1100 local time. On a specific day. > The calendar doesn't change. Of course it does, you've stored a UTC datetime, the timezone database is updated, the UTC datetime now maps to the wrong time (and because Samoa changed its offset by 24h it actually maps to the wrong day entirely every single time). > This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify. * while Pacific/Apia is UTC-11, you create a meeting for January 5th at 11 local * this is stored as 2012-01-05T22:00:00+0000 * tzinfo gets updated with Pacific/Apia at UTC+13 * your calendar now tells you your meeting is on January 6th at 11 local * you're a day late
      • mjevans 10y ago
        You're both correct. The scheduling library should be more upfront about /what/ is being agreed to and force the user to pick. P) The event is at a precise internationally recognized moment (better for co-ordination globally). R) The event is in local time (like a lunch date) and expected to remain colloquially fixed. In the case of the first you store a precise UTC timestamp and drop the timezone (it's UTC). In the case of the second you store /how/ to pick a UTC timestamp based on a time in a timezone.
    • tedunangst 10y ago
      Samoa did change the calendar. The local <-> utc mapping changed. In order to update the stored database, you need to convert all times to local with the old mapping, then convert to utc again with the new mapping.
  • vacri 10y ago
    Using one of the most extreme edge cases is not a good argument. How often is Samoa (or another small dateline-neighbour country) going to 'jump sides'?
    • masklinn 10y ago
      > Using one of the most extreme edge cases is not a good argument. 1. How is it not a good argument? It's an actual historical fact which is not yet 5 years old rather than some intellectual exercise, you can hardly go better than "this stuff happened not 5 years ago". 2. The only "extreme" part here is the magnitude of the drift, it's a clear example and demonstration of the issue. > How often is Samoa going to 'jump sides'? How is that relevant to the problem specifically and clearly existing? Does it matter if your calendar is 24h off or 6h off? Your system is FUBAR either way. > or another small dateline-neighbour country The dateline isn't even relevant, are you somehow trying to win a prize in missing the point?
      • vacri 10y ago
        > It's an actual historical fact It's actual historic fact that the gregorian calendar we use skipped 11 days, but I don't see your suggestion solving that. Again, it was "just magnitude". > Does it matter if your calendar is 24h off or 6h off? Your system is FUBAR either way. Your theoretical appointment-haver might not blink at an appointment at a normal time + 1 day in the future, but might blink when their appointments start in the early afternoon and continue until midnight. The fact is that if you skip days, then it doesn't matter if you use local or UTC time. > are you somehow trying to win a prize in missing the point? I'm not the cretin who thinks that timekeeping is a binary good/bad state. Some applications have troubles when they're milliseconds out. Others have quite a bit of lag time that they can handle. A daily to-do list just needs to appear on the right day, for example; DST means little to it.
    • toyg 10y ago
      Timezones change all the time. There are almost 200 countries in the world, some so large that even their sub-states can and do change timezone rules on their own (US, Russia, India, China...). This is why Linux distributions have a dedicated package listing timezone info that is updated almost weekly, and Windows has similar arrangements. Any solid datetime implementation better consider that time is not, in fact, immutable - even UTC can and will shift here and there.
• paulddraper 10y ago
  Sure, if you limit yourself to timestamps. But dates/times have much more notions than an instant. Like, that I have a recurring event every weekday at 9am local time. Or that the weekend is two days (hello, DST). And even if you only need timestamps, "Whenever dealing with users, use local tz" isn't exactly a magic wand either. Also, "unix timestamp" isn't exactly one data type. Sometimes you need greater precision than one second.
• PeterisP 10y ago
  "Always manipulate in UTC" fails for datetime distance computation. Two very common examples: For a recurring scheduled event, "Same time tomorrow" may require adding 24, 23 or 25 hours to the UTC time, depending on the TZ. The question "how many full days have elapsed between two timestamps?" may need to return 1 for 23.5 hour distance or 0 for 24.5 hour distance depending on the TZ. I'd be so happy if we all could agree that a day always has 24 hours, but that doesn't seem likely any time soon.