5 ms·

Back in '08 when the US dates of DST changed, I was working on a Java-based enterprise software product with a relatively large install base. It suddenly became

Back in '08 when the US dates of DST changed, I was working on a Java-based enterprise software product with a relatively large install base. It suddenly became known to a lot of customers that timezone tables are part of the JRE, and simply updating the OS wasn't enough to get proper time calculations in Java. It was a very stressful time getting customers with many different versions of Java across dozens of platforms properly updated. A lot of customers were running ancient versions of Java that were well past EOL, but we still helped them out. Needless to say, I'm very happy this might finally happen. I do not, however, envy whoever is now supporting that software. I'm sure there are folks that haven't touched their systems since the last DST change.

paxys 5y ago
Considering how frequently time zones around the world change, any OS or software that doesn't auto update them from a standard list at this point deserves to break.
- lastofthemojito 5y ago
  Sure, but I'd imagine on lots of threads discussing exploits, there are a lot of experts commenting, "Considering how frequently systems are exploited, any system that doesn't require Internet functionality shouldn't be on the Internet".
  - deleted 5y ago
    [deleted]
  - paxys 5y ago
    A system with correctly configured firewalls and other access controls which receives regular updates and zero day patches is still more secure than an offline one.
    - upbeat_general 5y ago
      Not sure how you reached that conclusion. A fully-airgapped system is definitely more secure as long as physical attacks aren’t a threat vector.
      - Breza 5y ago
        Just don't pick up any USB sticks you find in the parking lot
- snemvalts 5y ago
  Even digital watches that would last tens of years without battery changes? (and where BT would consume too much energy)
  - paxys 5y ago
    Why would such watches rely on time zone data at all to function correctly?
    - snemvalts 5y ago
      A lot have auto DST that switches DST automatically. And/or programmed timezones
      - paxys 5y ago
        If they switch automatically then they should also account for timezone changes. Otherwise they should offer a manual update option for the user. If a watch doesn't do either of those then I'd call it broken.
  - ericpauley 5y ago
    WWVB appears to support permannent disablement of DST [1]. [1] https://en.wikipedia.org/wiki/WWVB#DST_and_leap_second_warning https://en.wikipedia.org/wiki/WWVB#DST_and_leap_second_warni...
- humanistbot 5y ago
  You've obviously never worked with clients.
- lostcolony 5y ago
  "Auto update from a standard list" - please point me to this standard list. Note - I need to know for a given user at a given location what a millis from epoch equates to in local time, for times that could be before or after this change, so I need timezone conversions AND what dates they were in effect for. I also need some SLAs, and ideally someone I can pay; not much, but enough to feel confident I can get support and/or that it'll be around a decade from now.
  - paxys 5y ago
    You don't need to pay anyone for this – https://www.iana.org/time-zones https://www.iana.org/time-zones The tz database is public domain, and they have HTTP/FTP/rsync APIs. You probably don't even need to implement this yourself, since every modern OS pulls from this already.
    - lostcolony 5y ago
      Thanks; that is what I was looking for. Last time I had to work in detail with timezones (with the above reqs, plus some others), that didn't exist (based on the date for the RFC). As to having to/not having to implement this (and rely on the OS) - probably! I just know at the time I last dealt with this, every library I could find packaged their own TZ DB, and they were definitely not standard.
      - Macha 5y ago
        Which RFC? The RFC moving it to IANA in 2012? It's been in development in some way since the 80s [1], the current timezone names in it are from the 90s[2], and it was definitely already the standard timezone definitions when I started using Linux in the 00s. [1]: http://mm.icann.org/pipermail/tz/1986-November/008946.html http://mm.icann.org/pipermail/tz/1986-November/008946.html [2]: https://mm.icann.org/pipermail/tz/1993-October/009233.html https://mm.icann.org/pipermail/tz/1993-October/009233.html
        lostcolony 5y ago
jonah-archive 5y ago
Ooof, I remember that. At the time I was writing shipping logistics optimization software for LTL shipping, and many clients were using ancient warehouse inventory systems (lots of data uploads over ftp, etc) that couldn't easily be modified to account for the time change, uh, change. Very painful.
dekhn 5y ago
Huh. These days most systems I work with just use a shim into the system timezone tables (I just checked the Qt docs, as that's my preferred way to develop cross-platform apps).
- hermitdev 5y ago
  I think the landscape has shifted since the US rules were last changed in 2007. It was awful for pretty much everything that needed to be timezone aware and not just show some local time to a user. Dates & times were not yet even part of standard C++ (some support started in C++11). Boost got your part of the way there, but it's IANA timezone db support was thin. (It could handle current timezones, but not historical or future). I think MS even support IANA timezone db support on Windows somewhere. Windows' ability to handle historical timezone changes was also pretty limited, and the actually history provided was pretty slim. While I have no doubt should the DST change be made permanent will cause all sorts of issues with software (I mean, there's plenty of software, especially in embedded that still doesn't take into account the 2007 change), I personally welcome the end of a twice yearly switch. Which direction, I don't really care. I just want the switching to end.
- adrianmonk 5y ago
  It's probably because Java promises "write once, run anywhere". If you rely on the system timezone tables, you might have a different set of timezones available from one system to another or the rules for the same timezone might differ. And then code would behave differently on different operating systems. If instead you ship timezone tables with the Java Runtime Environment, then you can promise that (by default) the code will behave the same. It sucks that it creates extra maintenance burden (and lurking problems people may not be aware of), but that's the price you pay for decoupling.
  - dekhn 5y ago
    Yeah, when I read about the Java behavior I figured it was to get cross-platform consistency. All that I can say is that I concluded that the opposite approach (applications should be written to handle what the system tables provide through a shim API like Qt provides) makes more sense. I noticed this recently when I had to install some CA certs into my JRE when a java app didn't use the system ones.
anonu 5y ago
I remember this too. The major difference is things auto-update more frequently, and people have higher bandwidth connections. So it's less of a problem that 14 years ago, luckily.

paxys 5y ago

Considering how frequently time zones around the world change, any OS or software that doesn't auto update them from a standard list at this point deserves to break.

lastofthemojito 5y ago
Sure, but I'd imagine on lots of threads discussing exploits, there are a lot of experts commenting, "Considering how frequently systems are exploited, any system that doesn't require Internet functionality shouldn't be on the Internet".
- deleted 5y ago
  [deleted]
- paxys 5y ago
  A system with correctly configured firewalls and other access controls which receives regular updates and zero day patches is still more secure than an offline one.
  - upbeat_general 5y ago
    Not sure how you reached that conclusion. A fully-airgapped system is definitely more secure as long as physical attacks aren’t a threat vector.
    - Breza 5y ago
      Just don't pick up any USB sticks you find in the parking lot
snemvalts 5y ago
Even digital watches that would last tens of years without battery changes? (and where BT would consume too much energy)
- paxys 5y ago
  Why would such watches rely on time zone data at all to function correctly?
  - snemvalts 5y ago
    A lot have auto DST that switches DST automatically. And/or programmed timezones
    - paxys 5y ago
      If they switch automatically then they should also account for timezone changes. Otherwise they should offer a manual update option for the user. If a watch doesn't do either of those then I'd call it broken.
- ericpauley 5y ago
  WWVB appears to support permannent disablement of DST [1]. [1] https://en.wikipedia.org/wiki/WWVB#DST_and_leap_second_warning https://en.wikipedia.org/wiki/WWVB#DST_and_leap_second_warni...
humanistbot 5y ago
You've obviously never worked with clients.
lostcolony 5y ago
"Auto update from a standard list" - please point me to this standard list. Note - I need to know for a given user at a given location what a millis from epoch equates to in local time, for times that could be before or after this change, so I need timezone conversions AND what dates they were in effect for. I also need some SLAs, and ideally someone I can pay; not much, but enough to feel confident I can get support and/or that it'll be around a decade from now.
- paxys 5y ago
  You don't need to pay anyone for this – https://www.iana.org/time-zones https://www.iana.org/time-zones The tz database is public domain, and they have HTTP/FTP/rsync APIs. You probably don't even need to implement this yourself, since every modern OS pulls from this already.
  - lostcolony 5y ago
    Thanks; that is what I was looking for. Last time I had to work in detail with timezones (with the above reqs, plus some others), that didn't exist (based on the date for the RFC). As to having to/not having to implement this (and rely on the OS) - probably! I just know at the time I last dealt with this, every library I could find packaged their own TZ DB, and they were definitely not standard.
    - Macha 5y ago
      Which RFC? The RFC moving it to IANA in 2012? It's been in development in some way since the 80s [1], the current timezone names in it are from the 90s[2], and it was definitely already the standard timezone definitions when I started using Linux in the 00s. [1]: http://mm.icann.org/pipermail/tz/1986-November/008946.html http://mm.icann.org/pipermail/tz/1986-November/008946.html [2]: https://mm.icann.org/pipermail/tz/1993-October/009233.html https://mm.icann.org/pipermail/tz/1993-October/009233.html
      - lostcolony 5y ago

jonah-archive 5y ago

Ooof, I remember that. At the time I was writing shipping logistics optimization software for LTL shipping, and many clients were using ancient warehouse inventory systems (lots of data uploads over ftp, etc) that couldn't easily be modified to account for the time change, uh, change. Very painful.

dekhn 5y ago

Huh. These days most systems I work with just use a shim into the system timezone tables (I just checked the Qt docs, as that's my preferred way to develop cross-platform apps).

hermitdev 5y ago
I think the landscape has shifted since the US rules were last changed in 2007. It was awful for pretty much everything that needed to be timezone aware and not just show some local time to a user. Dates & times were not yet even part of standard C++ (some support started in C++11). Boost got your part of the way there, but it's IANA timezone db support was thin. (It could handle current timezones, but not historical or future). I think MS even support IANA timezone db support on Windows somewhere. Windows' ability to handle historical timezone changes was also pretty limited, and the actually history provided was pretty slim. While I have no doubt should the DST change be made permanent will cause all sorts of issues with software (I mean, there's plenty of software, especially in embedded that still doesn't take into account the 2007 change), I personally welcome the end of a twice yearly switch. Which direction, I don't really care. I just want the switching to end.
adrianmonk 5y ago
It's probably because Java promises "write once, run anywhere". If you rely on the system timezone tables, you might have a different set of timezones available from one system to another or the rules for the same timezone might differ. And then code would behave differently on different operating systems. If instead you ship timezone tables with the Java Runtime Environment, then you can promise that (by default) the code will behave the same. It sucks that it creates extra maintenance burden (and lurking problems people may not be aware of), but that's the price you pay for decoupling.
- dekhn 5y ago
  Yeah, when I read about the Java behavior I figured it was to get cross-platform consistency. All that I can say is that I concluded that the opposite approach (applications should be written to handle what the system tables provide through a shim API like Qt provides) makes more sense. I noticed this recently when I had to install some CA certs into my JRE when a java app didn't use the system ones.

anonu 5y ago

I remember this too. The major difference is things auto-update more frequently, and people have higher bandwidth connections. So it's less of a problem that 14 years ago, luckily.