From: Greg Ercolano <erco@(email surpressed)>
Subject: Daylight savings time changes
   Date: Tue, 27 Feb 2007 13:56:30 -0500

In case you didn't know, Daylight Savings Time dates will change
this coming month; starting March 2007:

    > DST will be March 11, 2007
    > DST will end November 4th 2007

Similar to Y2K, computer companies are stumbling over themselves
(myself included for Rush) to accommodate the changes to DST for
the upcoming month.

See this NIST page (National Institute of Standards and Technology)
for info: http://tf.nist.gov/general/history.htm#Anchor-16126

If you have Macs, you may have noticed a recent operating system update
that shows a 'DST' entry for the OS and for Java; I advise you take that
update if you want your computer clocks to show the correct time.

If you already 'clicked away' that Software Update dialog, you can
bring it back by clicking on the 'Blue Apple' (at the upper left)
and choose 'Software Update'. Be sure to install any items that include
'DST' in the update name.

There's probably similar updates for Windows and Linux; I don't know
what they are at this time. (Feel free to follow up to this thread)

I'm going to do some tests today to see if there's any DST issues with
Rush; I don't think there will be, as DST calculations are dependent on
OS config files, that likely have nothing to do with anything statically
compiled into Rush.

I'll follow up here with results.

Greg Ercolano wrote:

There's probably similar updates for Windows and Linux; I don't know
what they are at this time. (Feel free to follow up to this thread)

LINUX INFORMATION
-----------------

   I just updated linux, and I can tell you that you'll need to,
   at least:

	RESTART THE RUSH DAEMON AFTER MAKING TIMEZONE CHANGES

   ..or even better, reboot the box, as my tests show that other
   daemons may also be affected.

   According to my tests, the rushd daemon's C/C++ libraries *cached*
   the old timezone info, so even though the timezone files were updated,
   the daemon's C library had already cached the timezone info in memory;
   restarting the daemon was necessary to flush that cache.

   I was able to prove the C library's behavior by writing a small
   C program that runs ctime(3) in a while loop.. basically:

---- snip
#include <stdio.h>
#include <unistd.h>
#include <time.h>
int main(int argc, char**argv) {
    while ( 1 ) {
        long lt; time(&lt);
        fprintf(stderr, "ctime: %s", ctime(&lt));
        sleep(1);
    }
}
---- snip

   By starting this program /before/ applying the patch, and letting
   it continue to run as I applied the patches, I noticed it continued
   to report the WRONG time (eg. 03/11/07 2am instead of 03/11/07 3am)
   It's only when I restarted the program, it showed correct times.

   To me, this test /proves/ a reboot is needed should be done, even though
   some websites say this shouldn't be necessary. I beg to differ, based on
   the above test, to ensure daemons like crond/atd/syslogd show correct times.

   I did several tests where I warped the clock to 1:55am 03/11/07,
   and watched the behavior of the daemon's reporting time/dates
   as it ran through the Witching Hour. The daemon still showed standard time
   info after the 2am -> 3am jump; eg. 'rush -ljf' for newly submitted jobs
   still showed in standard time. But when I restarted the daemon, the same
   jobs that had been showing incorrect times now showed correct start time info.

   Because of this, I'd advise you REBOOT after making timezone changes,
   as likely all daemons (crond, atd, etc), not just rush, will have
   cached timezone info.

SEEING THE DST PROBLEM IN LINUX
-------------------------------
   It's important to be able to see the problem without warping the clock.

   Under linux, whether its redhat 6.1 or Fedora 3, you can do this simple
   test.

   If you're *not* up to date with the DST fix (eg. for the PST time zone),
   you will see:

# zdump -v PST8PDT | grep 2007
PST8PDT  Sun Apr  1 09:59:59 2007 UTC = Sun Apr  1 01:59:59 2007 PST isdst=0 gmtoff=-28800
PST8PDT  Sun Apr  1 10:00:00 2007 UTC = Sun Apr  1 03:00:00 2007 PDT isdst=1 gmtoff=-25200
PST8PDT  Sun Oct 28 08:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 PDT isdst=1 gmtoff=-25200
PST8PDT  Sun Oct 28 09:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 PST isdst=0 gmtoff=-28800

    ..the "Apr 1" and "Oct 28" entries shows I have the old info.

    When the DST patch is applied correctly, the zdump command should instead show,
    again, for PST:

# zdump -v PST8PDT | grep 2007
PST8PDT  Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 PST isdst=0 gmtoff=-28800
PST8PDT  Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 PDT isdst=1 gmtoff=-25200
PST8PDT  Sun Nov  4 08:59:59 2007 UTC = Sun Nov  4 01:59:59 2007 PDT isdst=1 gmtoff=-25200
PST8PDT  Sun Nov  4 09:00:00 2007 UTC = Sun Nov  4 01:00:00 2007 PST isdst=0 gmtoff=-28800


PATCHING MY LINUX MACHINES FOR DST
----------------------------------

    Just FYI, here's the one way I chose to update my linux boxes.

    These same steps worked on my old, old redhat 6.1 machine, and my more recent
    Fedora 3 machine. The paths and commands were all the same.

    There are probably easier ways (yum, rpms, etc), but I wanted to know
    what files were being modified for test purposes.

    I updated my fedora3 machine by downloading tzdata2007c.tar.gz from
    from: ftp://elsie.nci.nih.gov/pub/
    ..and in my case, saved it to /tmp and installed for the PST timezone with:

# mkdir /tmp/zoneinfo ; cd /tmp/zoneinfo; tar xfz /tmp/tzdata2007c.tar.gz
# zic -d /tmp/zoneinfo northamerica
# /bin/cp -p /tmp/zoneinfo/PST8PDT              /usr/share/zoneinfo/PST8PDT
# /bin/cp -p /tmp/zoneinfo/PST8PDT              /etc/localtime
# /bin/cp -p /tmp/zoneinfo/America/Los_Angeles  /usr/share/zoneinfo/America/Los_Angeles

    Note: you may want to save your previous files the above /bin/cp commands
    overwrite, in case you want to switch back and forth.

    After doing this, running the above zdump command showed the correct
    Mar 11/Nov 4 results.


--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Hmmm... What about on Windows?

Fran Z
R&D
LAIKA, Inc.

-----Original Message-----
From: Greg Ercolano [mailto:erco@(email surpressed)] 
Sent: Tuesday, February 27, 2007 12:23 PM
To: void@(email surpressed)
Subject: Re: Daylight savings time changes

[posted to rush.general]

Greg Ercolano wrote:
> There's probably similar updates for Windows and Linux; I don't know
> what they are at this time. (Feel free to follow up to this thread)

LINUX INFORMATION
-----------------

    I just updated linux, and I can tell you that you'll need to,
    at least:

	RESTART THE RUSH DAEMON AFTER MAKING TIMEZONE CHANGES

    ..or even better, reboot the box, as my tests show that other
    daemons may also be affected.

    According to my tests, the rushd daemon's C/C++ libraries *cached*
    the old timezone info, so even though the timezone files were
updated,
    the daemon's C library had already cached the timezone info in
memory;
    restarting the daemon was necessary to flush that cache.

    I was able to prove the C library's behavior by writing a small
    C program that runs ctime(3) in a while loop.. basically:

---- snip
#include <stdio.h>
#include <unistd.h>
#include <time.h>
int main(int argc, char**argv) {
     while ( 1 ) {
         long lt; time(&lt);
         fprintf(stderr, "ctime: %s", ctime(&lt));
         sleep(1);
     }
}
---- snip

    By starting this program /before/ applying the patch, and letting
    it continue to run as I applied the patches, I noticed it continued
    to report the WRONG time (eg. 03/11/07 2am instead of 03/11/07 3am)
    It's only when I restarted the program, it showed correct times.

    To me, this test /proves/ a reboot is needed should be done, even
though
    some websites say this shouldn't be necessary. I beg to differ,
based on
    the above test, to ensure daemons like crond/atd/syslogd show
correct times.

    I did several tests where I warped the clock to 1:55am 03/11/07,
    and watched the behavior of the daemon's reporting time/dates
    as it ran through the Witching Hour. The daemon still showed
standard time
    info after the 2am -> 3am jump; eg. 'rush -ljf' for newly submitted
jobs
    still showed in standard time. But when I restarted the daemon, the
same
    jobs that had been showing incorrect times now showed correct start
time info.

    Because of this, I'd advise you REBOOT after making timezone
changes,
    as likely all daemons (crond, atd, etc), not just rush, will have
    cached timezone info.

SEEING THE DST PROBLEM IN LINUX
-------------------------------
    It's important to be able to see the problem without warping the
clock.

    Under linux, whether its redhat 6.1 or Fedora 3, you can do this
simple
    test.

    If you're *not* up to date with the DST fix (eg. for the PST time
zone),
    you will see:

# zdump -v PST8PDT | grep 2007
PST8PDT  Sun Apr  1 09:59:59 2007 UTC = Sun Apr  1 01:59:59 2007 PST
isdst=0 gmtoff=-28800
PST8PDT  Sun Apr  1 10:00:00 2007 UTC = Sun Apr  1 03:00:00 2007 PDT
isdst=1 gmtoff=-25200
PST8PDT  Sun Oct 28 08:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 PDT
isdst=1 gmtoff=-25200
PST8PDT  Sun Oct 28 09:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 PST
isdst=0 gmtoff=-28800

     ..the "Apr 1" and "Oct 28" entries shows I have the old info.

     When the DST patch is applied correctly, the zdump command should
instead show,
     again, for PST:

# zdump -v PST8PDT | grep 2007
PST8PDT  Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 PST
isdst=0 gmtoff=-28800
PST8PDT  Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 PDT
isdst=1 gmtoff=-25200
PST8PDT  Sun Nov  4 08:59:59 2007 UTC = Sun Nov  4 01:59:59 2007 PDT
isdst=1 gmtoff=-25200
PST8PDT  Sun Nov  4 09:00:00 2007 UTC = Sun Nov  4 01:00:00 2007 PST
isdst=0 gmtoff=-28800


PATCHING MY LINUX MACHINES FOR DST
----------------------------------

     Just FYI, here's the one way I chose to update my linux boxes.

     These same steps worked on my old, old redhat 6.1 machine, and my
more recent
     Fedora 3 machine. The paths and commands were all the same.

     There are probably easier ways (yum, rpms, etc), but I wanted to
know
     what files were being modified for test purposes.

     I updated my fedora3 machine by downloading tzdata2007c.tar.gz from
     from: ftp://elsie.nci.nih.gov/pub/
     ..and in my case, saved it to /tmp and installed for the PST
timezone with:

# mkdir /tmp/zoneinfo ; cd /tmp/zoneinfo; tar xfz
/tmp/tzdata2007c.tar.gz
# zic -d /tmp/zoneinfo northamerica
# /bin/cp -p /tmp/zoneinfo/PST8PDT
/usr/share/zoneinfo/PST8PDT
# /bin/cp -p /tmp/zoneinfo/PST8PDT              /etc/localtime
# /bin/cp -p /tmp/zoneinfo/America/Los_Angeles
/usr/share/zoneinfo/America/Los_Angeles

     Note: you may want to save your previous files the above /bin/cp
commands
     overwrite, in case you want to switch back and forth.

     After doing this, running the above zdump command showed the
correct
     Mar 11/Nov 4 results.


-- 
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Fran Zandonella wrote:

[posted to rush.general]

Hmmm... What about on Windows?

    No test info yet.

    Before I can do any tests, I have to first upgrade my Win2K box to SP4
    before I can install the DST updates. That'll take a while.

    My opinion is you'll have no trouble under Windows, because they seem
    to force you to reboot when you install anything. And likely after a reboot,
    all will be fine.

	The Microsoft DST link is:
	http://support.microsoft.com/gp/cp_dst

	..the "IT Professionals" link takes you to:
	http://support.microsoft.com/gp/dst_it1

	..and the "Developers" link takes you to:
	http://msdn2.microsoft.com/en-us/vstudio/bb264729.aspx

    Rush does not keep date information for jobs in local time formats..
    it keeps everything in UTC time() converted format.. dates should
    all update correctly after the DST os patches are applied.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Greg Ercolano wrote:

Hmmm... What about on Windows?

    Before I can do any tests, I have to first upgrade my Win2K box to SP4
    before I can install the DST updates. That'll take a while.

WINDOWS DST RESULTS
-------------------

	I verified you have to also reboot Windows after making the
	DST change; it's the only way to make sure no programs running
	have old DST information cached after you apply the fix.

	I did a test proving this is the case..

TEST FOR DST CACHING IN THE C LIBRARY
-------------------------------------

	I did the same test I did with linux (previous message) under Windows
	using this small C program that runs ctime() in a loop:

---- snip
#include <stdio.h>
#include <windows.h>		// WINDOWS
#include <time.h>
int main(int argc, char**argv) {
    while ( 1 ) {
        long lt; time(&lt);
        fprintf(stderr, "ctime: %s", ctime(&lt));
        Sleep(1000);		// WINDOWS
    }
}
---- snip

	I compiled that, and left it lying around to do this test
	to make sure it crossed into the new timezone correctly:

1) First I warped the clock to 1:55AM March 11,
   putting the machine 5 minutes before the witching hour.

2) Then started the program in DOS window "A"; leaving it printing out
   the date/time in a loop once a second.

3) I applied the DST changes (see below)

4) Then I ran a new instance of my date/time program in DOS window "B"

5) Then I waited for 2am to strike.

	Just like in linux; Window "A" did NOT show the correct time;
	it went on to show 2am as if the DST jump didn't happen.

	But Window "B" did jump correctly; it 'sprang forward' straight
	to 3am as it should.



	So these results under windows are the same as Linux; the C library
	caches the timezone info when the program starts up, so changes made
	while programs are running are not 'seen' until the programs are restarted.

	Which means the only way to be sure the fix gets applied correctly
	is to restart all programs and daemons, which means *reboot*.

APPLYING THE WINDOWS DST FIX
----------------------------

	There's different options for the various versions of Windows.
	I have a win2K box, so this is what worked for me.

	Under Windows, after I dug down through the Win2K SP4 upgrade
	prerequisites, I ended up on this page that describes several ways
	to apply the DST fix:
	http://support.microsoft.com/kb/914387/en-us

	One way is to download and run a little 'TZEDIT' gui that lets you
	set the DST on/off times. I took this approach, as it was most
	relevant to me.

	Other ways included applying a rollup patch:
	http://support.microsoft.com/kb/931836/
	..which works if you have 2K server or XP, but not plain old 2K,
	so I skipped this one. And there was also a wacky regedit approach
	that looked totally insane, so I skipped that too.

	Using 'TZEDIT' was easy; just don't miss the extra step where you
	have to then go into the control panel and change the local timezone
	to a different zone, then back to the current zone, to make the change 'stick'.
	If you don't do that, the change won't really take effect. (I verified
	this myself by forgetting to do it the first time! ;)

	Anyway, there you have it. MTYEWTK about DST!!

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)