in reply to Impact of U.S. Daylight Savings Time changes in 2007 on Perl distribution/code

From reading the Perl docs, I've come to the same conclusion: Perl uses the O/S's to determine whether daylight savings time is in effect. Given the need to patch the underlying O/S, application programmers (in Perl, and everything else) may need to manage the DST switch explicitly for quite a while.

Another good reason to do everything in UTC.


Addendum

Poking through the Risks repository, specifically here, I've found out some potentially useful information: All versions of *ix, Windows NT and its derivatives (Windows 2000, XP, etc), and at least the more recent versions of the Mac O/S convert from GMT/UTC (these are almost, but not quite the same thing, by the way) to local time. The older Windows O/S kept local times.

emc

At that time [1909] the chief engineer was almost always the chief test pilot as well. That had the fortunate result of eliminating poor engineering early in aviation.

—Igor Sikorsky, reported in AOPA Pilot magazine February 2003.
  • Comment on Re: Impact of U.S. Daylight Savings Time changes in 2007 on Perl distribution/code

Replies are listed 'Best First'.
Re^2: Impact of U.S. Daylight Savings Time changes in 2007 on Perl distribution/code
by jbert (Priest) on Jan 07, 2007 at 17:25 UTC
    Another good reason to do everything in UTC.

    Absolutely. Like encoding characters as bytes, representing time (stored as time_t or UTC strings) in user-readable format is a user-interface issue (ditto for input).

    Normalise data to a canonical form at all the boundaries on input (and convert back to local settings on output) and a whole class of worries just go away.

    Just be sure that you conversions aren't lossy :-)

Re^2: Impact of U.S. Daylight Savings Time changes in 2007 on Perl distribution/code
by ysth (Canon) on Jan 07, 2007 at 18:17 UTC
    Given the need to patch the underlying O/S
    Yikes, what a pain. Especially given that the whole world doesn't automatically follow U.S. rules. Fortunately, sensible OS's store timezone data in data files, usually built from the zoneinfo database (which was updated and released 16 times in 2006).
      Very painful. I learned this week that patching Solaris and Windows O/S for DST 2007 changes is inadequate for some Oracle and Microsoft applications. For example: depending on the Oracle version, subsequent Oracle patches may be needed for the Oracle Rdbms software and Oracle JVM (optionally installed) in each database.

      Moreover, I understand that Microsoft apps have patching requirements that go beyond the O/S patching. The specific example I heard about this week is that Outlook versions prior to Outlook 2007 will need application patching else existing appointments will be an hour off come March 12th when the new DST rules go into effect (even if you patch the MS O/S for DST changes).

      So, this is just a off-hand sampling of potential issues I'm aware of. Kudos to kool delhite for bringing up this topic in a perl context.