My Debian Squeeze box DOESN'T spring forward

Although making such a change would be very much in line with the "volatile" repository, could it simply be that changes to the law over-ran changes to tzdata.

Also, tzdata is a package you can't not have installed. Unlike ntp or ntpdate.

Slackware puts out periodic updates to tzdata for it's various releases. I have no idea why Debian wouldn't.

I do have ntp installed though, so I don't know if my Slackware boxes would have handled it without ntp or not.

@jdixon: Your Slackware boxes would have done "spring forward" just fine. My SalixOS boxes did and that's just Slackware plus stuff. The updates for anything included in Slackware come from Slackware.

JD, I didn't say Debian _didn't_ put out updates, only that maybe this particular install missed them.

@jdixon: Missing a "spring forward" should be an issue only if you don't have current timezone data installed or you don't have your timezone configured correctly. Otherwise, the GNU libc should automatically handle the one-second difference between "2012-03-11 01:59:59 xST" and "2012-03-11 03:00:00 xDT".

NTP is only for synchronizing the kernel clock with an NTP server. It doesn't spring forward or fall back.

> Your Slackware boxes would have done "spring forward" just fine.

I expect so, Caitlyn. I was just noting that since I'd set up ntp and had it running, I couldn't verify that they had.

I know a tzdata update came out not that long ago, so I wouldn't expect any problems.

> I didn't say Debian _didn't_ put out updates...

Neither did I. :)

> NTP is only for synchronizing the kernel clock with an NTP server

Hmm. That's true. It's actually getting UTC from the ntp server, and should still be handling the local time with tzdata. So my boxes must have handled it properly, as they were all correct.

This post was mine -- I did have tzdata, didn't have ntp.

I narrowed the reason my Debian system didn't spring forward to something having to do with the laptop being in suspend the whole of Sunday. I resumed it on Monday morning and was an hour behind. Rebooting didn't change that.

I could have set the clock manually, I suppose. But since I usually run ntp on my Linux setups, I added it, and the clock almost immediately sprang forward.

That sounds like you're using local time in the CMOS clock.

If it's a 100% Linux laptop, I suggest switching to UTC in the CMOS, and updating the timezone settings accordingly.

OTOH, if you're dual-booting Windows, well...

(Funny aside: I started to type "dual-botting". Which, if you're also running Windows, is more than likely true.)

(Funny aside #2: "ruining Windows". Channeling Mr. Spooner in my fingers?)

"Ruining Windows"? Have you somehow started to think you're an upper-echelon MS executive? I recommend setting Windows aside entirely (at least disable the option in your boot menu) until you can regain mental stability.

- - -

PS: technically, you weren't actually spanneling Mr. Chooner, though I'm sure the phenomenon is somewhat similar.

Quoting:PS: technically, you weren't actually spanneling Mr. Chooner, though I'm sure the phenomenon is somewhat similar.

@BS - - Chooner?

@ComputerBob

http://en.wikipedia.org/wiki/Spoonerism