4 ms·

I don't think any of the DST complaints are legitimate. If doing work involved with timestamps, not keeping everything in GMT is questionable. GMT is the UTF-8

I don't think any of the DST complaints are legitimate. If doing work involved with timestamps, not keeping everything in GMT is questionable. GMT is the UTF-8 of timestamps: the low common-denominator rules. The datetime library is mechanism. DST is policy. Policy is wildly variable and your system library would be unmaintainable if it had to chase policy. Just say no.

lifthrasiir 3y ago
As long as you can't predict the future, some future date since a specific cut-off can't be reliably converted to UTC (not GMT, which does observe DST) anyway.
- graemep 3y ago
  GMT does not have DST. It is only slightly different from UTC. That said, you should really use UTC. I think you are confusing it with British Summer Time which is GMT +1
  - pasc1878 3y ago
    Being a pedant here. What is being confused is GMT/BST/(BDST) with the time in a location Greenwich. Currently the time in London is BST between end March to end of October and GMT the rest of the year. Historically the dates have changed and also had period where it was BST in the winter and BDST (GNT+2) in the summer, and also years with BST all year round. There are still people who suggest BST all year round (I think if Scotland when independent it could happen) Also now UK is not in the EU it is more free to change things.
  - jasode 3y ago
    >That said, you should really use UTC. No, that "store UTC everywhere" is often repeated but it's incorrect advice when applied to future human-constructed datetimes such as appointments or social events. Future "human-interpreted wall-clock" datetimes cannot be unambiguously stored as future UTC values with perfect roundtrip fidelity. I've tried to explain the difference in previous comment: https://news.ycombinator.com/item?id=19534843 https://news.ycombinator.com/item?id=19534843
    - Glyptodon 3y ago
      The number of times very smart people seem to think having to alter a pile of UTC times because their associated region has changed their DST behavior is better than having local zoneless and just changing TZDB always weirds me out.
    - graemep 3y ago
      That is a good point, but fortunately a rare case. The other problem is that when you are using human inputs such as appointments you may not know which is appropriate. If I arrange a meeting with someone in another timezone, and there is such a change, how can a system know whether I want the UTC time, my timezone, or the other person's timezone. I am not sure there is a good way to do this in many cases. As you say some culturally defined times are definitely tied to the local timezone, but a lot of things will not be. There is a loss of information, but that information may not be useful on many cases. I think I agree with you in that there is no universal solution. However, store UTC is probably good enough a lot of the time. In general, timezone changes would be announced well ahead of time so UTC would be fine except for times fixed far ahead. I have actually lived through timezone changes that were decided on in emergency circumstances (Sri Lanka faced with a severe electricity shortage) and the result was chaos. People genuinely did not know whether an appointment would take place in "old time" or "new time"! No system devised earlier could have coped with that because intent was no unambiguous.
      - Hackbraten 3y ago
        > how can a system know whether I want the UTC time, my timezone, or the other person's timezone A decent system will allow the user to make that choice on a case-by-case basis but assume the common case as a default. I've seen apps pull that off successfully, e.g. iCal.
- praash 3y ago
  A true observation, especially since many European countries (or just some citizens) wish to get rid of DST. However, ±1 hour is not much of an error when talking about a time delay of at least a year.
  - autarch 3y ago
    > However, ±1 hour is not much of an error when talking about a time delay of at least a year. It is if this a doctor's appointment or a meeting with a friend or ... you get my point.
    - macintux 3y ago
      I missed most of my last chance to see my cousin play college basketball because I trusted her college’s website, and it was off by an hour due to timezone confusion.
praash 3y ago
This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users. If I needed to define a daily alarm in a local wall clock time, I'd happily deal with a zoneless dateless hour-minute tuple and determine the alarm time by combining a date and a time using a timezone. Right after I'd convert that and handle the rest in UTC.
- pasc1878 3y ago
  You need to know more than that. Is the appoint meant 2pm in London or in New York. So for forward times you need a location as well as the date and time. Yes when it happens you store in UTC. In both cases you can display to user with local timezone. (Although if the London user is going top fly to NY they will still want to see the NY time and not their local time)
- autarch 3y ago
  > This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users. No, this only works for datetimes in the _past_. For future datetimes you often must store the datetime in the user's (IANA) timezone. Otherwise your application could be off. And your app could be off by more than one hour. In 2011 Samoa moved across the international date line. See https://www.theguardian.com/world/2011/dec/30/samoa-loses-day-date-line https://www.theguardian.com/world/2011/dec/30/samoa-loses-da....
  - Spivak 3y ago
    Thank god someone in the thread understands the problem. Everyone saying "just make everything UTC and convert" is both throwing away information and making it impossible to do future calculations. "Schedule a 1-1 with my boss every two weeks at 1 PM" If you take my local time zone, convert it to UTC which puts my meeting at say 9AM UTC, schedule every two weeks at 9AM UTC and convert back to my local time zone it will be wrong when I hit change DST. But if I instead store the (datetime, zone) pair when I say "1PM fourteen calendar days from now in zone" it will always be correct. The UTC "trick" only works when your problem domain is representing specific moments in time.
Kwpolska 3y ago
DST and local time are relevant in calculations when humans are involved. A user in Japan shouldn't be told it's still Sunday just because it's still Sunday somewhere in western Europe. If I set up a recurring meeting every Monday at 10:00, it shouldn't suddenly shift to 09:00 or 11:00 just because of a DST switchover.
- kroolik 3y ago
  What if the meeting is between people in EU and USA, where DST transitions occur at different moments?
  - rightbyte 3y ago
    Hmm ... if a problem is hard enough maybe just don't try to solve it? Treat the meeting time as a string, rather than a time, since it is ambiguous anyway what the organizer meant, and let the user figure out what the string means.
  - airstrike 3y ago
    Tell those people not to meet at 2am on the night DST changes
    - demondemidi 3y ago
      All the meetings are hosed for about two weeks. This is a known issue for anyone working with time zones that don’t change together.
  - Kwpolska 3y ago
    Calendars like Outlook let you specify a timezone for the event. If it's set to Europe/Warsaw, the US goes out of sync for a few weeks. If America/New_York, the EU does. This still isn't a problem for a meeting between LA and NY, for example (unless the meeting is in the middle of the night).
    - demondemidi 3y ago
Glyptodon 3y ago
I tend to prefer: - Things happen/happened at UTC times - Things will happen at zoneless time + IANA DB label. Though there are some edges. Obviously it's possible to pre-apply and convert to UTC, which is okay, but whether that makes sense to do in practice varies some. Future UTC time of often worthless for understanding human centric dates and times.
- Kwpolska 3y ago
  For past events, knowing the local time might be useful context. I'd store local time with UTC offset, or with IANA time zone name (which might change the UTC meaning if there's some change affecting past dates in the IANA database).
tremon 3y ago
If doing work involved with timestamps Of course, any argument becomes much easier if you're allowed to just discard half the purpose of the thing you're arguing about. The Python datetime library doesn't just exist to record timestamps. From the actual documentation: > The datetime module supplies classes for manipulating dates and times. > [..] the focus of the implementation is on efficient attribute extraction for output formatting and manipulation. Datetime manipulation is part of the explicit focus of the module. So why would you argue that we shouldn't expect said manipulations to be DST-aware?

lifthrasiir 3y ago

As long as you can't predict the future, some future date since a specific cut-off can't be reliably converted to UTC (not GMT, which does observe DST) anyway.

graemep 3y ago
GMT does not have DST. It is only slightly different from UTC. That said, you should really use UTC. I think you are confusing it with British Summer Time which is GMT +1
- pasc1878 3y ago
  Being a pedant here. What is being confused is GMT/BST/(BDST) with the time in a location Greenwich. Currently the time in London is BST between end March to end of October and GMT the rest of the year. Historically the dates have changed and also had period where it was BST in the winter and BDST (GNT+2) in the summer, and also years with BST all year round. There are still people who suggest BST all year round (I think if Scotland when independent it could happen) Also now UK is not in the EU it is more free to change things.
- jasode 3y ago
  >That said, you should really use UTC. No, that "store UTC everywhere" is often repeated but it's incorrect advice when applied to future human-constructed datetimes such as appointments or social events. Future "human-interpreted wall-clock" datetimes cannot be unambiguously stored as future UTC values with perfect roundtrip fidelity. I've tried to explain the difference in previous comment: https://news.ycombinator.com/item?id=19534843 https://news.ycombinator.com/item?id=19534843
  - Glyptodon 3y ago
    The number of times very smart people seem to think having to alter a pile of UTC times because their associated region has changed their DST behavior is better than having local zoneless and just changing TZDB always weirds me out.
  - graemep 3y ago
    That is a good point, but fortunately a rare case. The other problem is that when you are using human inputs such as appointments you may not know which is appropriate. If I arrange a meeting with someone in another timezone, and there is such a change, how can a system know whether I want the UTC time, my timezone, or the other person's timezone. I am not sure there is a good way to do this in many cases. As you say some culturally defined times are definitely tied to the local timezone, but a lot of things will not be. There is a loss of information, but that information may not be useful on many cases. I think I agree with you in that there is no universal solution. However, store UTC is probably good enough a lot of the time. In general, timezone changes would be announced well ahead of time so UTC would be fine except for times fixed far ahead. I have actually lived through timezone changes that were decided on in emergency circumstances (Sri Lanka faced with a severe electricity shortage) and the result was chaos. People genuinely did not know whether an appointment would take place in "old time" or "new time"! No system devised earlier could have coped with that because intent was no unambiguous.
    - Hackbraten 3y ago
      > how can a system know whether I want the UTC time, my timezone, or the other person's timezone A decent system will allow the user to make that choice on a case-by-case basis but assume the common case as a default. I've seen apps pull that off successfully, e.g. iCal.
praash 3y ago
A true observation, especially since many European countries (or just some citizens) wish to get rid of DST. However, ±1 hour is not much of an error when talking about a time delay of at least a year.
- autarch 3y ago
  > However, ±1 hour is not much of an error when talking about a time delay of at least a year. It is if this a doctor's appointment or a meeting with a friend or ... you get my point.
  - macintux 3y ago
    I missed most of my last chance to see my cousin play college basketball because I trusted her college’s website, and it was off by an hour due to timezone confusion.

praash 3y ago

This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users. If I needed to define a daily alarm in a local wall clock time, I'd happily deal with a zoneless dateless hour-minute tuple and determine the alarm time by combining a date and a time using a timezone. Right after I'd convert that and handle the rest in UTC.

pasc1878 3y ago
You need to know more than that. Is the appoint meant 2pm in London or in New York. So for forward times you need a location as well as the date and time. Yes when it happens you store in UTC. In both cases you can display to user with local timezone. (Although if the London user is going top fly to NY they will still want to see the NY time and not their local time)
autarch 3y ago
> This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users. No, this only works for datetimes in the _past_. For future datetimes you often must store the datetime in the user's (IANA) timezone. Otherwise your application could be off. And your app could be off by more than one hour. In 2011 Samoa moved across the international date line. See https://www.theguardian.com/world/2011/dec/30/samoa-loses-day-date-line https://www.theguardian.com/world/2011/dec/30/samoa-loses-da....
- Spivak 3y ago
  Thank god someone in the thread understands the problem. Everyone saying "just make everything UTC and convert" is both throwing away information and making it impossible to do future calculations. "Schedule a 1-1 with my boss every two weeks at 1 PM" If you take my local time zone, convert it to UTC which puts my meeting at say 9AM UTC, schedule every two weeks at 9AM UTC and convert back to my local time zone it will be wrong when I hit change DST. But if I instead store the (datetime, zone) pair when I say "1PM fourteen calendar days from now in zone" it will always be correct. The UTC "trick" only works when your problem domain is representing specific moments in time.

Kwpolska 3y ago

DST and local time are relevant in calculations when humans are involved. A user in Japan shouldn't be told it's still Sunday just because it's still Sunday somewhere in western Europe. If I set up a recurring meeting every Monday at 10:00, it shouldn't suddenly shift to 09:00 or 11:00 just because of a DST switchover.

kroolik 3y ago
What if the meeting is between people in EU and USA, where DST transitions occur at different moments?
- rightbyte 3y ago
  Hmm ... if a problem is hard enough maybe just don't try to solve it? Treat the meeting time as a string, rather than a time, since it is ambiguous anyway what the organizer meant, and let the user figure out what the string means.
- airstrike 3y ago
  Tell those people not to meet at 2am on the night DST changes
  - demondemidi 3y ago
    All the meetings are hosed for about two weeks. This is a known issue for anyone working with time zones that don’t change together.
- Kwpolska 3y ago
  Calendars like Outlook let you specify a timezone for the event. If it's set to Europe/Warsaw, the US goes out of sync for a few weeks. If America/New_York, the EU does. This still isn't a problem for a meeting between LA and NY, for example (unless the meeting is in the middle of the night).
  - demondemidi 3y ago

Glyptodon 3y ago

I tend to prefer: - Things happen/happened at UTC times - Things will happen at zoneless time + IANA DB label. Though there are some edges. Obviously it's possible to pre-apply and convert to UTC, which is okay, but whether that makes sense to do in practice varies some. Future UTC time of often worthless for understanding human centric dates and times.

Kwpolska 3y ago
For past events, knowing the local time might be useful context. I'd store local time with UTC offset, or with IANA time zone name (which might change the UTC meaning if there's some change affecting past dates in the IANA database).

tremon 3y ago

If doing work involved with timestamps Of course, any argument becomes much easier if you're allowed to just discard half the purpose of the thing you're arguing about. The Python datetime library doesn't just exist to record timestamps. From the actual documentation: > The datetime module supplies classes for manipulating dates and times. > [..] the focus of the implementation is on efficient attribute extraction for output formatting and manipulation. Datetime manipulation is part of the explicit focus of the module. So why would you argue that we shouldn't expect said manipulations to be DST-aware?