Why did my time change on Sunday? 1

[PeteBull]

I know it was suppose to because of Daylight Saving Time, but I don't think it should have according to the daylight-savings-rules table:

display daylight-savings-rules Page 1 of 2
DAYLIGHT SAVINGS RULES

Rule Change Day Month Date Time Increment

0: No Daylight Savings

1: Start: first Sunday on or after March 11 at 02:00 01:00
Stop: first Sunday on or after November 1 at 02:00
2: Start: first on or after at : :
Stop: first on or after at :



Am I missing something? I'm glad it worked, because I didn't think of checking the DST Rules until Monday, but I'd like to understand WHY it worked.

 

[DontDeleteMeAgain]

the first Sunday of March was last Sunday, so according to your rule it would change.

 

[SF0751]

Your DST rule is incorrect. The correct rule for the US is
[tt]2
DAYLIGHT SAVINGS RULES

Rule Change Day Month Date Time Increment

0: No Daylight Savings

1: Start: first Sunday on or after March 8 at 02:00 01:00
Stop: first Sunday on or after November 1 at 02:00

2: Start: first on or after at : :
Stop: first on or after at :
[/tt]

Susan
"An education isn't how much you have committed to memory, or even how much you know. It's being able to differentiate between what you do know and what you don't."
- Anatole France

 

[PeteBull]

DontDeleteMeAgain - look at the rule again. "after March 11"

SF0751 - I agree, the rule is incorrect, so why did the time change correctly?


The time changed correctly in spite of the rule being incorrect. I am trying to figure out WHY the time changed correctly since the rule is incorrect.

 

[SF0751]

I'm not sure, but in reading the Avaya documentation for the DST patches, it sounds like the various DST rules are already built in. So I think that the system was updated correctly in spite of the incorrect rule, since the system "knew" what the correct rule should have been.

Maybe someone else can come up with a better answer?

Susan
"An education isn't how much you have committed to memory, or even how much you know. It's being able to differentiate between what you do know and what you don't."
- Anatole France

 

[1a22ip]

Maybe the system responded to your Time server?

Just a thought
ED

1a2 to ip I seen it all

 

[Mitch672]

The Linux patch may have been applied, and that may have adjusted the Linux date/time, which adjusts CM's time as well.

Do you have an S-Series Server, as opposed to an older CSI/SI/R?

Do an "update_show" or "swversion" from the linux shell and post the results

Mitch


AVAYA Certified Specialist

 

[AvayaTier3]

When a DST patch is installed, rpms update tzdata files in the linux server.

Time is changed in linux based on this, not what is in CM for daylight savings rules

dadmin@s8500b> /usr/sbin/zdump -v /etc/localtime | grep 200[78]
/etc/localtime Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isds
t=0 gmtoff=-18000
/etc/localtime Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isds
t=1 gmtoff=-14400
/etc/localtime Sun Nov 4 05:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 EDT isds
t=1 gmtoff=-14400
/etc/localtime Sun Nov 4 06:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 EST isds
t=0 gmtoff=-18000
dadmin@s8500b> rpm -qa tzdata
tzdata-2007d-1.el4


A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"

bsh

35 years Bell, AT&T, Lucent, Avaya
Tier 3 for 25 years and counting

http://bshtele.com

 

[Ronster]

Make sure you fix this before next Sunday or it might change again!

_______________________________________________________________
"There's probably no God. Now stop worrying and enjoy your life." - Bendy Bus

 

[AvayaTier3]

First example used 2007 / 2008. Substitute the year you are looking for in the command.

dadmin@s8500b> /usr/sbin/zdump -v /etc/localtime | grep 2009
/etc/localtime Sun Mar 8 08:59:59 2009 UTC = Sun Mar 8 01:59:59 2009 MST isdst=0 gmtoff=-25200
/etc/localtime Sun Mar 8 09:00:00 2009 UTC = Sun Mar 8 03:00:00 2009 MDT isdst=1 gmtoff=-21600
/etc/localtime Sun Nov 1 07:59:59 2009 UTC = Sun Nov 1 01:59:59 2009 MDT isdst=1 gmtoff=-21600
/etc/localtime Sun Nov 1 08:00:00 2009 UTC = Sun Nov 1 01:00:00 2009 MST isdst=0 gmtoff=-25200


A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"

bsh

35 years Bell, AT&T, Lucent, Avaya
Tier 3 for 25 years and counting

http://bshtele.com