Linux Systems and the New DST

An anonymous reader writes "The recent changes in the Daylight Saving Time will affect virtually all computer systems in the US one week from now. Microsoft has been busy preparing Windows users for 'Y2DST,' and all the major Linux distributions have also issued patches. How can you be sure your Linux systems are ready, and what can you do to get them ready if they're not? This how-to article at Linux-Watch answers both questions in simple language and with easy-to-follow instructions."

Comments

Simple

[SIGBUS]

Set you system to run on UTC. No daylight savings hassles to worry about.

A very simple *nix test

[Iphtashu Fitz]

$ date --date="Mar 25 15:00:00 UTC 2006"
$ date --date="Mar 25 15:00:00 UTC 2007"

If the output of both shows the same time (eg. 10:00 EST) then you've got a problem. If they show different times (eg. 10:00 EST and 11:00 EDT) then your system is ok.

Win vs Lin

[stry_cat]

Funny how with Linux there isn't any danger of your entire system breaking. I know we spent every day since the Windows patches were relased, testing and make sure the patches don't break anything. So far our Exchange server had to be restored from backup once already b/c all the calendar entries got screwed up.

Re:Win vs Lin

[EveryNickIsTaken]

If you're competent in your Windows adminstration, then there isn't any danger of your entire system breaking.

Re:Win vs Lin

[Anonymous Coward]

If you're competent in your Windows adminstration, then there isn't any danger of your entire system breaking.

Exactly. All the competent Windows admins have already switched to Linux.

Root Cause

[overshoot]

Or, of course, you could have dealt with the root cause of the problem: the biannual insanity of running around changing otherwise perfectly good clocks.

How many of you, after all, have told your State legislatures that this is stupid and it's time to opt out?

Re:Root Cause

[Rob the Bold]

How many of you, after all, have told your State legislatures that this is stupid and it's time to opt out?

I like DST. I know how to set what clocks I have that still need to be changed. I enjoy the extra light at the end of the day. I am aware that I could just get up an hour early and try to convince everyone else that I have to deal with to do the same, but DST accomplishes that. Also, I live in a city that spans state lines, so having one state opt out would be a real hassle.

I would much rather lobby my legislature to allow wine to be shipped directly to my door. For crying out loud, I can get ammo delivered (and left on the doorstep) without even a signature, why can't I buy wine directly.

So, for all of those who dislike DST, try this: Just get up an hour later.

Re:NTP?

[overshoot]

How does this work with NTP? Will the system just stay up-to-date from another system that understands the new rules, or does NTP all work on UTC so that it's not aware of this, or something?

NTP will keep you system clock (as Heaven intends) coordinated with UTC.

However, if you're using an old zoneinfo file for local time, the interpretation of that UTC time is something else again, and NTP won't help you at all.

(Well, assuming you don't live in Arizona or Hawaii. Indiana's timing sucks, doesn't it?)

Beware JVM Problems

[tritonman]

If you have systems running JVM 1.3 that interact with systems using 1.4 or above, beware, there are issues in how they implemented the fix in 1.3. In Java 1.3, the DST change is applied to ALL years, including prior to 2007, so if you have a remote object on 1.3 give a date to an application running in 1.4 (as a binary object, not just text) then it will cause problems, it will set it to 1 hour off, if you don't use timestamps, the default will be midnight, so one hour off will be the previous day. This has caused a bunch of problems where I work.

How may we help you?

[djupedal]

"Hello - this is Manny and I will be your corporate level support concierge for this session - how may I help you?"
"Oh, Hi Manny, this is Stuart and I'm at our corporate IT HQ. We need help with the new DST configuration, please."

"Ok, Stuart, I'll be happy to provide whatever help I can, if you will just tell me the name of the corporation you're with, along with the contract ID and your callback number, you can hang up and I'll call you back so we can get things started."
"Ummm...Manny...excuse me, but I've never quite understood why you people always ask for the name of the corporation right off...what's up with that, if I may ask?"

"Well, Stuart, in our effort to provide the best quality service, we need to know upfront which company we are serving so we can insure that our responses fit with such things as non-disclosures, corporate culture, etc. As an example, since this incident deals with DST, if you are with Siemens, we're instructed to use twenty-four hour time, such as the time now being sixteen-forty-two hundred hours. If you are with Hertz Car Rental, the time is four forty-two pm."

"Oh, I see. Well, I'm with Microsoft, Manny, so what does the system say you should tell me?"
"Microsoft - I see. Well, Stuart, the big hand is on the four and the little hand is......."

Re:NTP?

[E-Lad]

I've seen and heard a lot of people say "I run NTP, I'm immune to this". Sadly, they're just showing that they don't know how NTP works, even on a basic level.

NTP as a protocol tracks the number of seconds elapsed since 1 January, 1900 UTC. It has absolutely zero knowledge of timezones or what they mean. Your NTP daemon of choise just sits there keeping your system clock reasonably accurate with UTC time and it's the relevant libc C time functions that read that UTC time, then read in the set zoneinfo data, and combine the two to give you and your apps local time.

Recent? It was two years ago...

[binaryspiral]

It was two years ago that this was signed into affect... this shouldn't be the rush that Microsoft, Cisco, and all the rest are making it. Slackers wasted one and a half years doing almost nothing... and now we get this.

Re:Looks like I'm screwed then

[forrestt]

You're posting to Slashdot about a problem with a date? And you think you're gonna get screwed? I'm not sure if this is redundant or wishful thinking. :)

Multiple timezone meetings

[farnz]

To give you an example of a meeting that spans several timezones; we needed to hold a teleconference with people in the UK, Australia and the US. Within the US, a company with offices in New York and San Francisco faces the same issue; you have people in different timezones, who need to agree on a time.

It's not possible to get a perfect solution to the problem. The best design I've seen stores times in UTC, together with a description of the entry timezone and the offset. Each user has a current local timezone (and it's assumed that users who travel will track these problems for themselves). When a change to DST comes along, the administrator can do some or all of the following:

• Adjust meetings such that meetings entered in the timezone that's changing are at the same local time (but a different UTC time).
• Adjust meetings such that meetings entered in the timezone that's changing are at the same UTC time (but a different local time).
• Alert everyone who's involved with a meeting where one or more participants are in a timezone that's changing to check that the time is still valid.

The system also allows users to override the entry timezone on a per-entry basis. This means that I can enter a meeting in the UK marked as 9am Atlanta time, and be confident that it'll not only appear properly, but that if Atlanta's timezone changes on me, it'll be updated properly.