5 ms·

How often do time zone rules change? That seems like a fairly rare event. If you're talking about daylight savings time, the date library you're using to conver

How often do time zone rules change? That seems like a fairly rare event. If you're talking about daylight savings time, the date library you're using to convert local time to UTC should account for that.

icebraining 9y ago
There's always changes happening. Just this year, Southern Chile changed its summer time zone offset, Haiti started observing DST and Mongolia stopped doing that.
- openasocket 9y ago
  Seriously?! Man, dealing with time can just never be simple...
  - _jal 9y ago
    Time, to me, is the canonical example of "things that people think should be easy, aren't". It has everything - complex, constantly changing "business" rules, exceptions generated essentially randomly by a shadowy cabal[1] nobody's ever heard of, "impossible" situations like the 11 days that never happened and other technically arbitrary calendar edits[2], multiple silly base conversions, really weird rules for picking certain dates[3], lots of opportunities for making fencepost errors, and lots of other things. Which leads me to my rule with time programming: Never fail to use a solid library, unless you're unfortunate enough to be writing one. This[4] is a great, necessary but not sufficient book if you have to do that. [1] https://en.wikipedia.org/wiki/International_Earth_Rotation_and_Reference_Systems_Service https://en.wikipedia.org/wiki/International_Earth_Rotation_a... [2] For example, https://en.wikipedia.org/wiki/Swedish_calendar https://en.wikipedia.org/wiki/Swedish_calendar [3] https://en.wikipedia.org/wiki/Easter#Computations https://en.wikipedia.org/wiki/Easter#Computations [4] https://www.amazon.com/Calendrical-Calculations-Nachum-Dershowitz/dp/0521702380 https://www.amazon.com/Calendrical-Calculations-Nachum-Dersh...
    - deepsun 9y ago
      Don't even mention how to calculate number of weeks in a year! It's often needed in real world programming for business reports, yet Joda-time library still doesn't support weeks not starting on Monday (like USA-ones) for that.
0x0 9y ago
This happens all the time, and sometimes even with just a few days heads-up. Here's a great example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457938 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457938
manigandham 9y ago
It doesnt have to be rules, time zones have relative and changing references against UTC, for example daylight saving time which is 2x per year in the US. If you schedule a meeting for 4pm Tuesday next week, but DST happens Friday this week, you still want the meeting on 4pm Tuesday next week. The local timezone and local timestamp is necessary for that.
- openasocket 9y ago
  That doesn't sound right. If you have a local timestamp with the date and the time and convert it to UTC, shouldn't the datetime library look up the rules for this timezone and convert it correctly? Isn't that the whole point of having timezones be more than offsets?
  - manigandham 9y ago
    What doesn't sound right? You might be saying the same thing. To store this appointment correctly, you store the timezone of the appointment (let's say EST) and the timestamp within that timezone (4pm). So the final version is 16:00 EST. You can store a UTC version as well, but you need the local timestamp and timezone first. If you only store the timezone with a UTC timestamp, when you convert back after DST shifts you'll end up with 3pm or 5pm (depending on the shift), not the expected 4pm for the actual meeting. UTC in this case is not the anchor, the local timestamp the user set for the meeting is.
    - openasocket 9y ago
      No, I mean you make the appointment for December 3rd at 10:00am in Eastern Time (ET), and then you convert it to UTC to put into the database. Your local->UTC conversion library looks at the date and notices that this occurs during Daylight Savings Time for ET, and uses the correct offset when converting. Unless the rules about DST change between now and that meeting this is completely correct, you don't need to store the local timestamp at all.
      - manigandham 9y ago

icebraining 9y ago

There's always changes happening. Just this year, Southern Chile changed its summer time zone offset, Haiti started observing DST and Mongolia stopped doing that.

openasocket 9y ago
Seriously?! Man, dealing with time can just never be simple...
- _jal 9y ago
  Time, to me, is the canonical example of "things that people think should be easy, aren't". It has everything - complex, constantly changing "business" rules, exceptions generated essentially randomly by a shadowy cabal[1] nobody's ever heard of, "impossible" situations like the 11 days that never happened and other technically arbitrary calendar edits[2], multiple silly base conversions, really weird rules for picking certain dates[3], lots of opportunities for making fencepost errors, and lots of other things. Which leads me to my rule with time programming: Never fail to use a solid library, unless you're unfortunate enough to be writing one. This[4] is a great, necessary but not sufficient book if you have to do that. [1] https://en.wikipedia.org/wiki/International_Earth_Rotation_and_Reference_Systems_Service https://en.wikipedia.org/wiki/International_Earth_Rotation_a... [2] For example, https://en.wikipedia.org/wiki/Swedish_calendar https://en.wikipedia.org/wiki/Swedish_calendar [3] https://en.wikipedia.org/wiki/Easter#Computations https://en.wikipedia.org/wiki/Easter#Computations [4] https://www.amazon.com/Calendrical-Calculations-Nachum-Dershowitz/dp/0521702380 https://www.amazon.com/Calendrical-Calculations-Nachum-Dersh...
  - deepsun 9y ago
    Don't even mention how to calculate number of weeks in a year! It's often needed in real world programming for business reports, yet Joda-time library still doesn't support weeks not starting on Monday (like USA-ones) for that.

0x0 9y ago

This happens all the time, and sometimes even with just a few days heads-up. Here's a great example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457938 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457938

manigandham 9y ago

It doesnt have to be rules, time zones have relative and changing references against UTC, for example daylight saving time which is 2x per year in the US. If you schedule a meeting for 4pm Tuesday next week, but DST happens Friday this week, you still want the meeting on 4pm Tuesday next week. The local timezone and local timestamp is necessary for that.

openasocket 9y ago
That doesn't sound right. If you have a local timestamp with the date and the time and convert it to UTC, shouldn't the datetime library look up the rules for this timezone and convert it correctly? Isn't that the whole point of having timezones be more than offsets?
- manigandham 9y ago
  What doesn't sound right? You might be saying the same thing. To store this appointment correctly, you store the timezone of the appointment (let's say EST) and the timestamp within that timezone (4pm). So the final version is 16:00 EST. You can store a UTC version as well, but you need the local timestamp and timezone first. If you only store the timezone with a UTC timestamp, when you convert back after DST shifts you'll end up with 3pm or 5pm (depending on the shift), not the expected 4pm for the actual meeting. UTC in this case is not the anchor, the local timestamp the user set for the meeting is.
  - openasocket 9y ago
    No, I mean you make the appointment for December 3rd at 10:00am in Eastern Time (ET), and then you convert it to UTC to put into the database. Your local->UTC conversion library looks at the date and notices that this occurs during Daylight Savings Time for ET, and uses the correct offset when converting. Unless the rules about DST change between now and that meeting this is completely correct, you don't need to store the local timestamp at all.
    - manigandham 9y ago