Possible bug in DST patches
I am running Trusted Solaris 8 12/02 x86
I have installed patches 125235-01 and 125237-01. It appears the spring forward time change works however the fall back time change does not seem to be losing an hour. I performed the following steps to test the time changes.
Spring forward time change:
1. Set the time using 慸ate 031101592007?which sets the time to Sun Mar 11 01:59:00 CST 2007
2. Using the date command I verified the time springs ahead and changes to Sun Mar 11 03:00:00 CST 2007 skipping the 2 am hour.
This tells me the spring forward worked.
Fall back time change:
1. Set the time using 慸ata 110401592007?to set the time to Sun Nov 4 01:59:00 CST 2007
2. Using the date command I tried to verify that the time would fall back and count the 1 am hour again but it did not. The date continued into the 2 am hour normally.
Because of this I am gussing there may be a bug in the patches.
If I am doing something wrong or if there is a better way to test the time change please let me know. Thanks
Josh
[1084 byte] By [
fcbsecia] at [2007-11-26 19:27:22]
# 1
> I am running Trusted Solaris 8 12/02 x86
>
> I have installed patches 125235-01 and 125237-01. It
> appears the spring forward time change works however
> the fall back time change does not seem to be losing
> an hour. I performed the following steps to test the
> time changes.
>
> Spring forward time change:
> 1. Set the time using 慸ate 031101592007?which sets
> the time to Sun Mar 11 01:59:00 CST 2007
This is an annoying way to test. I would prefer to run
'zdump -v <TZ> | grep 2007'
> Fall back time change:
> 1. Set the time using 慸ata 110401592007?to set the
> time to Sun Nov 4 01:59:00 CST 2007
The local time 1:59:00 occurs twice on November 4th. Which one did you set it to?
> Because of this I am gussing there may be a bug in
> the patches.
I doubt it.
This exact issue has been mentioned in the forums before.
--
Darren
# 3
> OK. I think I see what you are saying. First I want
> to make sure we are both talking about 24 hour time
> and not 12 hour time. In 24 hour time I understand
> the 0100 hour would occur twice; The first in DST and
> the second pass not in DST. I am not sure which time
> the 'date 110401592007' command I ran set the time
> in.
The second.
> Does the OS automatically put the new date in the
> second pass through of the 0100 hour?
Apparently.
> If so there may
> not be a bug at all but if that was the case how
> could the fall back time be tested?
Run
perl -le 'print scalar localtime 1143504000' and
perl -le 'print scalar localtime 1175040000'
If you're in a US timezone that follows Daylight Saving time, the first will show a time on March 27 2006 (Standard time) and the second a year later on March 27 2007 (Daylight Saving Time). The two should have local times one hour apart. If they do not, then you're probably not ready.
An alternative is to simply ask zdump for information about your particular tiemzone.
zdump -v $TZ | grep 2007. You should see the correct transition dates for 2007.
Alternatively, if you *really* want to change the clock on the computer, don't change it by specifying a local time (which as you've seen is ambiguous). Change it by specifying a UTC time and the -u flag. That's unambiguous.
--
Darren
