LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Timezone EDT -> EST issue with 13.37? (http://www.linuxquestions.org/questions/slackware-14/timezone-edt-est-issue-with-13-37-a-912141/)

bassplayer69 11-06-2011 07:18 AM

Timezone EDT -> EST issue with 13.37?
 
Either KDE or Slackware failed to fall back an hour this morning.

Dump of /etc/localtime:

Code:

/etc/localtime  Sun Nov  6 05:59:59 2011 UTC = Sun Nov  6 01:59:59 2011 EDT isds
t=1 gmtoff=-14400
/etc/localtime  Sun Nov  6 06:00:00 2011 UTC = Sun Nov  6 01:00:00 2011 EST isds
t=0 gmtoff=-18000

output of the date command:

Code:

# date
Sun Nov  6 08:13:08 EST 2011

actual date: Sun Nov 6 07:13:08 EST 2011

The time didn't fall back one hour.

That's interesting. I executed tzselect and received the following results for TZ='America/Detroit'

Code:

The following information has been given:

        United States
        Eastern Time - Michigan - most locations

Therefore TZ='America/Detroit' will be used.
Local time is now:        Sun Nov  6 08:17:54 EST 2011.
Universal Time is now:        Sun Nov  6 13:17:54 UTC 2011.
Is the above information OK?
1) Yes
2) No
#?

Which is not correct since its 07:17:54 EST

Slackware 13.37 64bit

ntp is not setup.

KDE version - whatever is shipped with Slackware 13.37

jmccue 11-06-2011 07:46 AM

Hi,

EDIT: sorry, did not see you did what was below, does Mich use a different time that NY, what is below is for NY:

Worked for me :)
Give this a try, it will tell you about your default timezone settings:

/usr/sbin/zdump -v /etc/localtime | grep 2011

for EST/EDT I get, and if it does not match what you get maybe you have a old timezone db

/etc/localtime Sun Mar 13 06:59:59 2011 UTC = Sun Mar 13 01:59:59 2011 EST isdst=0 gmtoff=-18000

/etc/localtime Sun Mar 13 07:00:00 2011 UTC = Sun Mar 13 03:00:00 2011 EDT isdst=1 gmtoff=-14400

/etc/localtime Sun Nov 6 05:59:59 2011 UTC = Sun Nov 6 01:59:59 2011 EDT isdst=1 gmtoff=-14400

/etc/localtime Sun Nov 6 06:00:00 2011 UTC = Sun Nov 6 01:00:00 2011 EST isdst=0 gmtoff=-18000


Jack

the_penguinator 11-06-2011 08:36 AM

I'm in Ontario and use EST5EDT as my timezone when setting machines up. Fallback happened as expected this morning.

tronayne 11-06-2011 09:38 AM

Quote:

...does Mich use a different time that NY...
The four counties of Dickinson, Gogebic, Iron and Menominee, in the western Upper Peninsula, are in the Central Time Zone; the rest of the state (most of it) is in the Eastern Time Zone, same time as New York. That's the "Michigan" setting for those four counties, otherwise you'd choose Eastern.

Hope this helps some.

Richard Cranium 11-06-2011 02:36 PM

What glibc-zoneinfo package do you have installed?

Mine (which worked correctly) is glibc-zoneinfo-2.13-noarch-4

ChrisAbela 11-06-2011 03:16 PM

Set the Hardware Clock to the current System Time:

# hwclock --systohc

bassplayer69 11-06-2011 07:24 PM

Quote:

Originally Posted by Richard Cranium (Post 4517456)
What glibc-zoneinfo package do you have installed?

Mine (which worked correctly) is glibc-zoneinfo-2.13-noarch-4

I have glibc-zoneinfo-2.13_multilib-noarch-4alien

bassplayer69 11-06-2011 07:27 PM

Quote:

Originally Posted by tronayne (Post 4517238)
The four counties of Dickinson, Gogebic, Iron and Menominee, in the western Upper Peninsula, are in the Central Time Zone; the rest of the state (most of it) is in the Eastern Time Zone, same time as New York. That's the "Michigan" setting for those four counties, otherwise you'd choose Eastern.

Hope this helps some.


Not so. when I run tzselect I have the two Michigan options:

Code:

2) Eastern Time - Michigan - most locations
14) Central Time - Michigan - Dickinson, Gogebic, Iron & Menominee Counties

I selected 2 since I'm not in the U.P.


BTW: I manually fixed it by using the "date -s" command.

I'll have to see if it moves forward next spring.

Richard Cranium 11-06-2011 08:44 PM

Quote:

Originally Posted by bassplayer69 (Post 4517647)
I have glibc-zoneinfo-2.13_multilib-noarch-4alien

Hmm. Has anyone else running multilib seen a problem? (I don't expect the OP to answer this one. :) )

kfritz 11-06-2011 10:26 PM

I go through this every 6 months or so. I google, I search linuxquestions, I listen to my wife say "It works fine on Windows", then I set the time manually and promise myself to solve it, and then forget.

Running 3 Slackware, home workstation (13.37, 64-bit), laptop (current, 32), and an always-on crufty old PIII (current, 32). Only the PIII has the correct time right now.

So I have a theory: having the hardware clock set to local time (the default) means that you have to have the machine running during the time-change to work correctly. My workstation and laptop were off last night.

Right? Wrong? Should I just switch to UTC hw clock to solve this?

T3slider 11-06-2011 11:30 PM

Quote:

Originally Posted by kfritz (Post 4517713)
So I have a theory: having the hardware clock set to local time (the default) means that you have to have the machine running during the time-change to work correctly. My workstation and laptop were off last night.

Right? Wrong? Should I just switch to UTC hw clock to solve this?

I believe this is correct unless you use a properly configured ntpd (and set it to start at boot time via /etc/rc.d/rc.ntpd), which, in Slackware, is set to allow the first adjustment to be big.

the_penguinator 11-07-2011 11:07 AM

got this here glibc-zoneinfo-2.13_multilib-noarch-4alien and the laptop was in "suspend to ram" and it came up fine with the correct time on Sunday

bassplayer69 11-07-2011 11:13 AM

Quote:

Originally Posted by kfritz (Post 4517713)
I go through this every 6 months or so. I google, I search linuxquestions, I listen to my wife say "It works fine on Windows", then I set the time manually and promise myself to solve it, and then forget.

Running 3 Slackware, home workstation (13.37, 64-bit), laptop (current, 32), and an always-on crufty old PIII (current, 32). Only the PIII has the correct time right now.

So I have a theory: having the hardware clock set to local time (the default) means that you have to have the machine running during the time-change to work correctly. My workstation and laptop were off last night.

Right? Wrong? Should I just switch to UTC hw clock to solve this?

Exactly. The Windows 7 VM I have worked fine. So, during the transition from EDT to EST and EST to EDT we're supposed to leave the computers on over night so it works? That's pretty lame... Just saying...

I don't mind setting the correct time twice a year, but this is the 21st century after all.

mrclisdue 11-07-2011 01:06 PM

Couldn't this issue be resolved by running /etc/rd.d/rc.ntpd, as mentioned in T3slider's post?

Doesn't windows automagically update its time settings because there's a time server running?

cheers,

bassplayer69 11-07-2011 03:11 PM

Quote:

Originally Posted by mrclisdue (Post 4518176)
Couldn't this issue be resolved by running /etc/rd.d/rc.ntpd, as mentioned in T3slider's post?

Doesn't windows automagically update its time settings because there's a time server running?

cheers,

I was planning on setting up the ntpd information as suggested, but with my Windows 7 VM, no, I don't have it set to go query a time server for the date/time.


All times are GMT -5. The time now is 04:47 PM.