Either KDE or Slackware failed to fall back an hour this morning.

Dump of /etc/localtime:

output of the date command:

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'

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

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

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

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.

What glibc-zoneinfo package do you have installed?

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

Set the Hardware Clock to the current System Time:

# hwclock --systohc

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

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

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.

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

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?

1 members found this post helpful.

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.

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

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.

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.