Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.

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

by kool_delhite (Acolyte)
on Jan 07, 2007 at 14:37 UTC ( [id://593399] : perlquestion . print w/replies, xml ) Need Help??

kool_delhite has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

As far as I know Perl uses the date/time functionality based on the operating system settings, hence as long as the operating system is ready for it, Perl should be good.
I also don't think perl manages timezone data internally. I would appreciate if someone could comment on this and let me know if there are any changes that we need to do to our Perl distributions/code to be complaint with U.S. Daylight Savings Time changes in 2007.

kool delhite
  • Comment on Impact of U.S. Daylight Savings Time changes in 2007 on Perl distribution/code

Replies are listed 'Best First'.
Re: Impact of U.S. Daylight Savings Time changes in 2007 on Perl distribution/code
by swampyankee (Parson) on Jan 07, 2007 at 15:32 UTC

    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.


    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.


    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.
      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 :-)

      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.

Re: Impact of U.S. Daylight Savings Time changes in 2007 on Perl distribution/code
by diotalevi (Canon) on Jan 07, 2007 at 19:46 UTC

    Also be aware that data-handling code in perl may also need to be updated. DateTime comes to mind but there's surely others.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

      The CHANGES file for DateTime-TimeZone-0.37 indicates that both versions 0.36 (2005-04-21) and 0.37 (2005-08-22) were based on version 2005i of the Olson tz database. This implies that 2005i or thereabouts was the first version of the tz database to incorporate the planned 2007 North American Daylight Saving Time changes. It also means that DateTime has been DST2007-ready since early 2005.

      The current version of DateTime::TimeZone is 0.57 (2006-11-27), which is based on version 2006p of the tz database (the current version). In general, it's probably a Good Idea to frequently update DT::TZ and, thereby, the underlying Perl implementation of the Olson tz database. There's also a utility named parse_olson in the tools/ directory of the DT::TZ distribution for generating the Perl modules from the tz database files without having to upgrade DT::TZ itself.


        As if to demonstrate how cool and up-to-date the Perl DateTime project is, it's principal architect and maintainer, Dave Rolsky, announced on the perl.datetime newsgroup the release today of DateTime-TimeZone-0.58, which is based on version 2007a of the Olson tz database, which was also just released today.
        Date: Mon, 8 Jan 2007 13:36:51 -0600 (CST) To: datetime <> Subject: ANNOUNCE: DateTime::TimeZone 0.58 Message-ID: <> From: (Dave Rolsky) 0.58 2007-01-08 - This release is based on version 2007a of the Olson database. -dave
        When I posted this yesterday, I know I first checked the FTP archive to confirm the current version and the files were for 2006p. Today, the files are for version 2007a. This implies that Dave has automated the detection of new versions of the Olson tz database and the consequent rebuilding and redistribution of DateTime::TimeZone. Slick!


Re: Impact of U.S. Daylight Savings Time changes in 2007 on Perl distribution/code
by Corion (Patriarch) on Mar 06, 2007 at 14:15 UTC

    Jan Dubois posted the results of his dive into Win32 localtime behaviour on p5p:

    What I learned about Windows and Daylight Saving Time today

    Basically, if $ENV{TZ} is set, MSVCRT.dll does the calculations itself and the latest version of MSVCRT as of today hasn't been updated to account for the new USA DST rules. There seems to be a hotfix for that.

    If $ENV{TZ} is not set, the current rules will apply but also be applied to the past.

    If $ENV{TZ} is not set, and you're running Vista/LongHorn, the current rules will apply and not be applied to the past, as Vista and upwards support a database of historical changes.

Re: Impact of U.S. Daylight Savings Time changes in 2007 on Perl distribution/code
by smithers (Friar) on Mar 05, 2007 at 19:05 UTC
    A bit of a DST tangent, for what it's worth.

    If you have not yet sorted out your Oracle database and/or Oracle Application Server software patches for DST2007 then dive into it immediately. With Oracle databases and Oracle app servers, the term "patch" should be replaced with "process" -- a very tedious process in some cases. Also: Oracle 10g uses timezone-aware data-types inside the SYS data dictionary so is more prone to required DST2007 patching. As for Oracle App Server: even more patching (processes) need to be dealt with. To top it off, Oracle delivered some major recent rewrites of their DST support notes (e.g. key Oracle Metalink support Note: 359145.1 was completely rewritten last week on: 2/28/07).

    On a positive note: Oracle's Opatch utility is Perl-based and the Oracle Perl scripts I used to apply patches and query the patch inventory worked very well.