Preparing Your Datacenters for DST Changes?

Cheeze asks: "As I am sure some of you know, Daylight Saving Time is slated to change this year thanks to The Energy Policy Act of 2005. This means nothing to the large majority of the population except they will either sleep late one day or have to commute in the dark. To a select few, this is a crunch time akin to the Y2K fiasco, only there has been almost zero publicity recently. These select few are the ones responsible for updating the millions of computers, both servers and workstations, with the new time zone information. For newer servers, this usually means just install a patch and reboot (which is slightly more than mildly inconvenient). For older servers, this is basically an 'End of Life' declaration. Servers running software for which no patch is available will be unable to update their own clocks. This doesn't seem like such a big deal until you realize Microsoft is only offering patches for Windows XP and beyond, and Sun will not be supporting Solaris 7 and older. That should knock a large percentage of the computers 1 hour off for a few weeks this spring. What are you doing in your datacenters to prepare?"

Are you saying..

[Anonymous Coward]

..that your servers don't use GMT?

Re:

[afidel]

They do, however if they have different ideas of what the offset should be for the timezone then things like kerberos tickets don't work. This is because the time is sent as UMT, if you manually change the clock to display the correct time then you effectively change the local idea of UMT because the computer backcalculates the UMT time from the displayed time and the offset from your timezone location. This is a big deal. In fact this is one of my biggest projects for Q1-07, and all because someone thinks

Re:

[bluephone]

Oh please, come on. I can't stand Bush any more than the next Democrat but even I am not going to go so far off the deep end to say that this is a scheme to put money in the pockets of IT companies. Something people need to learn about crooked politicians is that they only do things for others when it benefits them. Bush has been accused of favoring big oil for obvious reasons, his connections to big oil, but no one is going to say he's going to benefit from a windfall IT upgrade cycle. If he was, he wouldn

Re:

[s4m7]

What more shall I rant on concerning the hyporcracy and blindedness of the Liberal mindset?

Wow, I was right there with you until I realized you're just as crazy but in the opposite direction. Please don't use the word Liberal to mean "Ignorant Paranoid", and I'll try and refrain from using Conservative to mean "Incompetent Profiteer" because not all of us fall into your fallacious extremes.

Re:

[WgT2]

Point taken.

What are you doing in your datacenters to prepare?

[Anonymous Coward]

Using UTC.

Re:What are you doing in your datacenters to prepa

[Anonymous Coward]

Mod parent up. ISTM that you're better off if all computers have their hardware clocks set to UTC and the conversions to local time take place at the last possible time in the clients (if at all). If a user wants to use some client software or OS that doesn't understand the silly daylight savings rules (which are extremely crazy in some places); at least they don't damage anything in the datacenter and will only confuse themselves.

OTOH, what kind of evil company won't even give as trivial a patch as updating a time-zone file to their customers!?! If I had any such software and the company still existed I'd be wanting a full refund.

Re:

[DaveK08054]

OTOH, what kind of evil company won't even give as trivial a patch as updating a time-zone file to their customers!?!

Only true for systems that were built using shared time-zone files to begin with. I know of at least one "UNIX Like" real-time OS that was built with the time-zone table as data in a library that was then statically linked into all of the executables that used it. It might have made some sense in a real-time and/or embedded OS to do it that way, but it means you need to rebuild and replace all of those executables. If you then factor in all of the versions of all of those, it becomes a monstrous task.

Re:

[hummassa]

s/rebuild and replace/binary patch/

come on, after all, it's just ONE (at most FOUR) bytes that will change with this in the whole executable.

You also have to look for what you applications do

[LordKronos]

Thats a good idea, but won't always solve all of your problems. Here's a problem I experienced recently with one of our web apps.

We have a web event calendar where people can schedule events (for far into the future). When people input an event, they specify the date/time it will begin/end. The application then converts the date/time into a unix timestamp and stores it in the database. Later, when an event is being viewed, the timestamp is converted back to a textual date/time.

The conversion from local time to timestamp is done via PHP functions, which uses the systems timezone file. The OS patch to fix this problem simply updates the timezone file and everything should automatically work.

This is fine and dandy for most things, but I ran into one small glitch. For any events that are scheduled between the new start of DST and the old start of DST (roughly a 3 week period), if they were created BEFORE the patch was applied, they are now off by 1 hour AFTER the patch is applied.

The 1 hour difference is simple enough, and I might not have even noticed...or if I had, I probably would have just blamed it on user error when entering the data. However, this caused a strange side effect. The application built a secondary index to simplify searching for events. The index consisted of the event_id and the starting timestamp truncated to midnight. Of course, for those events in that 3 week period that were created before the patch was applied, they now had an index timestamp that was actually 1 AM. Of course, this caused events to mysteriously disappear from the calendar. You could search for them, but not see them when browsing.

I wasted a good couple of hours on this problem (thinking at first that it was isolated to a single event) before I finally did an analysis of the entire index and discovered that almost all events in that 3 week period were wrong. Then it instantly dawned on me what had happened.

Re:You also have to look for what you applications

[denelson83]

> This is fine and dandy for most things, but I ran into one small glitch. For any events that are scheduled between the new start of DST and the old start of DST (roughly a 3 week period), if they were created BEFORE the patch was applied, they are now off by 1 hour AFTER the patch is applied.

Perhaps if you had inputted your events on your program's terms by scheduling them one hour early -- since your program didn't know about the DST change, but you did -- then, after you apply the patch, your even

Re:

[Marillion]

This is fine well and good except - all UNIX systems (Linux, *BSD included) already work in UTC and convert to localtime on the fly.

Try the following on any UNIX system...

TZ=UTC xclock &
TZ=EST5EDT xclock &
TZ=PST8PDT xclock &

and you will see all three xclock windows with different times. The REAL problem of the Timezone change is that Noon of March 12th, 2007 is now an hour off from what we used to assume it would be.

Europe

[AnriL]

Does this affect European time zones and summer times in any way? I presume not, and the only effect we might see is incorrect time zone in e.g. mail headers from the US, if sent from an unpatched mail server with the wrong time. Or am I forgetting something?

Re:

[baldass_newbie]

Is that even the case? Don't most emails take their timestamp from the sender's client?
I believe that's the case with Lotus Notes. I am not a Sys Admin, so I don't know. But it would seem like most of this is handled at the OS level anyway. We have a couple days to patch yet, right?

After Y2K, I doubt most folks will lose sleep over this one. (That is if anyone is still in their same job.)

Re:

[Lord Bitman]

Is that even the case? Don't most emails take their timestamp from the sender's client?

Unfortunately, no. Outlook and Thunderbird both often sort by whatever the server claims the original sending time was, as evidenced by the ocassional "ancient mail" or "forever mail" you might see.

[though these bugs may have been fixed by now.. since they're so stupid]

Re:

[dark_knight_ita]

Does this affect European time zones and summer times in any way?

No, it won't.

Not this year

[Silver Sloth]

But it's generally true that what the US does today we Europeans will do next year. Furthermore, if it's found that the change in Daylight Savings does have energy use benefits, then I can see that the benefits outweigh any drawbacks.
The good thing is that when we get around to doing it our US colleages will have found all the problems!

Re:

[mightyQuin]

and the only effect we might see is incorrect time zone in e.g. mail headers from the US, if sent from an unpatched mail server with the wrong time. Or am I forgetting something?

Yes, you are forgetting mail headers from Canada :)

Avoid the problem in the US

[ziegast]

In the US, move your servers to Arizona or eastern Indiana or Hawaii or Alaska, so you don't have to deal with time zone changes anymore.

-ez

Re:Avoid the problem in Canada

[thomasdz]

Move your Datacenters to Saskatchewan...nice little province

Re:

[Zontar The Mindless]

Mine's already in Queensland, thanks. :)

Re:

[tscheez]

I'd rather they be in Newfoundland

Re:

[dadragon]

Cod can't type :)

Re:

[saskboy]

"Cod can't type :)"

Neither can wheat, but at least it doesn't slime up the keyboard.

Sadly, even in SK, the computer would need patching, so that when the person moves to Alberta, their computer time can be correctly set automatically when they arrive. Meanwhile VCRs and other devices pre-programmed to switch to DST are just going to remain "broken" forever. Yet another monument to the Bush years in government -- all in the name of saving 1% of the State's oil a year, when they could be saving 40% easily by

Re:

[_mythdraug_]

All of Indiana will honor DST this year. (Yet another change to have to be prepared for)

Re:

[fwittekind]

Indiana already _does_ honor DST. :(

Re:

[dodongo]

Indiana in its entirety honored DST in 2006. Previous to that, 77 counties did not -- only those around Chicago metro, Louisville metro, and Evansville changed times before (IIRC, my description of the location of the DST counties may be a bit fuzzy).

In any event, my iBook automatically observed the change, and it was nothing more than a matter of setting my desktop to New York time rather than Indianapolis.

Because there were already time zone definitions that Indiana was moving into, there wasn't a big de

Re:

[user2048]

"move your servers to Arizona ..."

But not to the Navajo Nation, which covers northeastern Arizona and follows DST. But the Hopi reservation would be OK. (It's in Arizona, surrounded by the Navaho reservation, and does not follow DST.)

Dump DST!

[kherr]

This arbitrary change is annoying, doesn't even accomplish what the original goals were (energy saving), and DST has outlived its utility. Simple solution, stop using DST! If Arizona can function, so should the rest of us be able to. I sort of joke, but I've made the decision to abandon DST usage in my personal life. No more adjusting my computers or running around the house resetting every appliance with a digital clock. I can easily adjust meeting times and such in my head when interacting with the DST-ho

Re:

[krzysztof]

Arizona functions well without DST because it's pretty far south, and the length of days doesn't change too much.

For those of us further north, DST is helpful, because having the sun rise at 4am and set at 8pm is wasteful, as most people don't start their days until much after 4, and their evenings certainly don't end at 8.

There was an interesting article [slate.com] in Slate a while ago arguing that it's not DST that should go, but time zones altogether.

Re:

[billdar]

most people don't start their days until much after 4, and their evenings certainly don't end at 8.

Obviously you're not a parent...

I'm more concerned of a switch back to the old....

[Antony-Kyre]

I'm more concerning of a switch back to the old DST (the one we had in 2006) if they decide it's the energy saving isn't good enough. How difficult would it be to unpatch out systems?

Re:I'm more concerned of a switch back to the old.

[brunascle]

they'd probably be patched through the same means. so if you survived the patch to the new DST, you'll be able to get a new patch to remove it.

Re:

[Cheeze]

you wouldn't remove a time zone patch, you would apply a new one that would change it back. once something is in the time zone data, it will be there for all of time. In the future, you never know when you might need to translate from the current time to the beginning of the dark ages (Around April 2006).

Can't be done

[XanC]

You can never "unpatch" this. You can add an additional patch which would specify the new rules, which would coincide with the old rules.

The thing is, a change like this is always and forever. If at any point in the future, even after this law has been rolled back, you want to know about time during this period, your system will have to know what rules were in effect at the time.

Re:

[Antony-Kyre]

Think of it this way. Take Microsoft for example. I think they only have timezone patches for some of the Windows versions.

Maybe a few years pass with the new DST rules, then the government pulls a 180 and decides to go back to the old DST. What if Microsoft decides not to support some of the versions they allowed to be patched before? They may cover WinXP right now, but who says they will 3-5 years from now?

This goes for other operating systems. Will any business care to bother to provide patches to redo i

Servers should be on UTC anyway

[Anonymous Coward]

There is no reason for having a single server clock on non-UTC. DST, even if it was to stay the same forever, makes things a pain in the arse (once a year, an hour happens twice).

Your client should convert the timezone. For a client machine, it's not much hassle just to go into clock settings and change it.

Worst case is web-apps - the server clock should be UTC, but you still need to convert the time zone in the client-facing PHP/Perl/Java/etc code. There you're just looking at a patch to the language runtime or whatever.

Re:

[ozbon]

Exactly what I was going to say.

Even on the web-apps I write, I always convert to GMT (or UTC, whichever terminology you care to use) rather than shafting about with time-changes, time-zone issues, and all that cack.

Mind you, I also rarely (if ever) use the timestamps as an identifier either, for similar reasons.

I suspect that if a server/db is using timestamps (including microtime, or whatever) as a unique identifier, then that's a whole new world of hurt.

Re:People should be on UTC anyway

[anon mouse-cow-aard]

Timezones have outlived their usefulness. They were a great improvement over every village setting it's time as before timezones existed, but nowadays, you never know when something is on tv (except using an electronic program guide) and there is so much long distance interaction (ie. tech support in India, R&D division in China, etc...) that telling time has become a real hassle. If you work in a company of any scope, there are lots of meetings, and many are missed because people didn't notice the tim

Re:

[Bob Uhl]

Unix hosts use UTC internally, but dates are displayed according to the process's time zone setting--hence the need for Unix patches (and the problems since older version of Solaris, AIX & HP-UX are still in use just about everywhere). The OS will still run along quite happily, but cron, at and anything else which cares about time will still behave oddly. It won't necessarily cause major issues, but it will be a chore.

I can't recall off the top of my head if time zone data are stored as text informa

Dammit

[Timesprout]

I just got my servers switched over from the Julien to the Gregorian calender. Now this. When will it ever end.

Re:

[Cyberax]

You think it's funny...

I have helped to maintain some computers in my local Orthodox Christian church. Orthodox Church _still_ uses Julian calendar (that's why Orthodox Christmas is celebrated on Jan 7), so I had to install patches that add Orthodox calendar support to Windows. It was not funny.

Re:

[MobileTatsu-NJG]

"I just got my servers switched over from the Julien to the Gregorian calender. Now this. When will it ever end."

You think that was bad? You should have been around for the BC to AD conversion. Yikes.

BC to AD

[camperdave]

You should have been around for the BC to AD conversion.

We thought we were going to be fine with that here, as we had some wise men who worked out when they were going to start. We were planning on just using an integer for number of years:positive for AD, negative for BC. However, some idiot politician somewhere decided to start labelling the years at 1 instead of 0, so now we've got an out-by-one bug every time you try to do a calculation that crosses the AD/BC boundary.

Re:

[Amazing Quantum Man]

That's why they dumped the Antikythera Mechanism. It couldn't handle the Y0K change.

Where to get time zone info source files from

[Anonymous Coward]

This should fix the problems for your Unix based machines. You can download a set of time zone source files from ftp://elsie.nci.nih.gov/pub/ [nih.gov], these files are in the public domain. From these files you can build a full set of zoneinfo files (read the man page for zic(1)), DON'T FORGET TO BACKUP YOUR CURRENT ONES IN CASE OF PROBLEMS!! For most Linux based distros this is in a package called tzdata (which will compile the source files into zoneinfo files for you). zic(1) should put the compiled files into the right directory for you. These source files should work with most zic(1)'s, if not you may need to massage them with sed or perl. Don't forget to update /etc/localtime (or whatever other mechanism your OS uses, /etc/timezone et al) to set your localtime to the right zoneinfo file.

Re:

[tricorn]

This also applies to all Mac OS X machines as well, of course. Apple will supply a new set of timezone files in a patch (if they haven't already), and there's absolutely no reason it won't be available for every version of OS X (since they should be the exact same files, the format hasn't changed). Doesn't Windows use a similar method? I thought pretty much everything had switched over to zic-based timezone files (which also takes care of all those pesky leap-seconds that everyone seemed to be so worried

Re:

[Anonymous Coward]

To my knowledge, windows still puts the local time in the CMOS clock! I learned to ignore the clock when dual-booting windows on a machine running linux with "RTC is UTC" option set.

Re:

[deniable]

Windows still uses local time and adjusts the clock for DST. The bigger problem is that it only stores a single set of dates so you have to update every year that the dates are changed.

Re:

[plambert]

The patch was in Mac OS X 10.4.5, I believe. I've seen no announcement or suggestion of new timezone files for any earlier releases of Mac OS X.

The Java 1.4.2_09 shipping with Mac OS X 10.4.x doesn't include the timezone changes, nor will it. Unless Apple ships a new Java 1.4.2, the only Java supporting the new timezone changes on Mac OS X is Java 5.

It also looks like WebObjects uses its own timezone files, and these haven't been updated in quite a while. Anyone doing any time/date manipulation in a WO a

Re:

[tricorn]

Apple really should release updated timezone files as an update for all versions, there's no reason not to. Failing that, it would be very easy for someone to provide an unofficial update to fix it, either by copying the files from 10.4 or just compiling them from the updated sources.

I'm surprised that Java doesn't just use the C library routines for that functionality on platforms where it is available, but I see that you're right, 1.4.2 does not do it correctly, 1.5 does (on OS X 10.4.8).

Re:

[tchuladdiass]

Well, for Windows servers that may work, but not on Unix type servers. Here's why.
The system clock (which isn't the same as the CMOS real-time clock) is set to UTC. Whenever an app requests the time, it is returned to the app in UTC. The app then calls a localtime() function to convert UTC to whatever the local time is, by refering to the appropriate timezone table. However, some apps will record time in log enteries using UTC (and do the conversion when the log is displayed), others will store time stam

Re:

[metamatic]

Any program keeping its logs in local time should be shot.

Like Linux and every major Unix [ath0.com], you mean?

Re:

[tchuladdiass]

The simple fix for this is to edit the rc script that starts syslog, and have it "export TZ=UTC && syslog"; then all the syslog entries will be in UTC.

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[nbvb]

Even if you use NTP, your OS still needs to recognize when to switch from EST to EDT (or PST to PDT, etc.)

What's worse (at least for us) is that the JVM has its own daylight-savings-time rule handling ..... way to go. Gotta patch that too.

Not quite true...

[oDDmON oUT]

"...Microsoft is only offering patches for Windows XP and beyond"

They are offering support for Windows 2000, free with the right volume license, $$$ without, or they have made a manual registry hack available (which I don't have handy because I'm posting from home).

And before you ask, there are companies that still specify Win2K server and workstation to run their software, Thompson/Prometric being one of them, which is how I came to find this out.

Re:

[labtec6]

You can always export the following keys from an XP machine:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Eastern Standard Time

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\TimeZoneInformation

Then just import it into a 2000 machine. Reboot and Ta Dah!

Re:

[bconway]

Does Windows 2000 understand the "Dynamic DST" sub-key? The manual method on the MS page [microsoft.com] just shows a standard DST entry.

Re:

[labtec6]

It is just a workaround. There won't be a hotfix for Windows 2000. XP and up, with the hotfix, understands Dynamic DST (Vista and Longhorn by default).

You'd have to change it manually if the need arises.

Re:

[Cheeze]

in other words, your grandma will have the wrong time on her windows 2000 computer for 6 weeks out of the year.

Patch to change DST?

[Sique]

I only had to chance it once (on Win98 if I remember correctly) and there it was just an regedit call. No reboot required. At this time Win98 was switching the DST about a month wrong in MET, and I had to correct that. There is also a Microsoft Utility called tzedit [microsoft.com], which displays and modifies the time zone rules. To have it affect the displayed time, you can go in the Control Panel, choose Date & Time and hit Ok. Then it will refresh the timezone information according to the changes you made with the tzedit.exe utility.

A more complete description of the necessary registry changes is at
Microsoft Knowledgebase 914387 [microsoft.com].

But as someone already wrote in an earlier post: Set your servers to use NTP, either from your local nameservers or from *.pool.ntp.org and have it automatically adjust for DST.

Re:

[GC]

But as someone already wrote in an earlier post: Set your servers to use NTP, either from your local nameservers or from *.pool.ntp.org and have it automatically adjust for DST.

And as someone corrected them - NTP servers give out standard time and the local system adjusts it to the local timezone, whatever that is set to.

Re:

[0racle]

Thank you for that link.

Re:

[Cheeze]

actually, an NTP server isn't going to help you. NTP server give out GMT/UTC already so they won't even change. Your computer relies on time zone rules to relate your local computer time to UTC. So, even if you are using an NTP server, you're still going to be generating the wrong time come March if you live in one of the affected areas and havn't updated your time zone rules.

Re:

[techno-vampire]

I checked tzedit, but, alas, it's for NT and up only. Not applicable to Win98. Thanx anyway.

Re:

[I_Wrote_This]

Set your servers to use NTP, either from your local nameservers or from *.pool.ntp.org and have it automatically adjust for DST.

That would only affect the current time, which isn't much use if you are scheduling something to occur next month and the DST change occurs in between. The system needs to know about future (and past) DST changes in order to display all dates correctly. If you ever use a date (rather than just a time) you need more than just NTP synchronizing.

Overhyped

[evilviper]

To a select few, this is a crunch time akin to the Y2K fiasco,

Uhh, no.

For newer servers, this usually means just install a patch and reboot (which is slightly more than mildly inconvenient).

It's not inconvenient at all, unless you really think 2+ years of lead time isn't enough, and your systems really won't be rebooting even once in that entire period of time... Not likely.

For older servers, this is basically an 'End of Life' declaration. Servers running software for which no patch is available will be un

Re:

[Cheeze]

I don't think you work in a datacenter then. Once our servers are configured and running, there should NEVER be a reason to reboot them. In fact, when we have an odd server failure, the server usually has been up since it was first put in the datacenter. We are just now getting failures of systems put up in the late 1990s. Sure we have new systems as well, but there are critical systems still running old hardware because it works and a reboot is too much of an outage to take.

If you don't think it could be i

Re:

[dhasenan]

Using UNIX? Just patch the timezone definitions. You don't have to reboot, though you may have to restart some applications.

Using Windows? You have to reboot once a month anyway, if your server faces the outside at all. Otherwise, you can just train your employees to use the time the server thinks it is. Ugly, but if you can't handle ten minutes of downtime on a server, that's the way to do it.

Of course, if you can't handle ten minutes of downtime, you have duplication. So why not patch the backup, test it

Re:

[valdis]

Actually, I *do* work in a data center. Our server room is over a quarter of an acre in size - so we *do* have the "patch and reboot hundreds/thousands problem" (you want fun? Try rebooting an 1,100 node cluster without anybody noticing ;) And if I deployed a system that couldn't tolerate a reboot without having a hot-failover or loadbalancing solution in place, I'd have my head handed to me on a platter.

I mean, come *on* - if you have an older-hardware system that "a reboot is too much of an outage', WTF

Re:

[Cheeze]

Exactly. most of these older systems have NEVER been rebooted. Rebooting them would cause a substantial amount of them to fail for various reasons.

I think with zic, patching java, and restarting the affected time-sensitive processes (syslog, cron, java), it should be possible to avoid rebooting.

Re:

[valdis]

The *real* fun comes when you encounter a system that has been kept up-to-date patchwise, and configuration changes made as needed, but never rebooted.

Then when you *do* need to reboot, you discover that some misapplied patch or config change from 2 years before was working as long as the the system kept running - but there was no possible way to get a clean correct startup.

Blegga. :)

(Another reason to have a spare system - that way you can *test* this stuff in a controlled fashion....)

Re:

[Cheeze]

I have seen that problem many times. Most recently, the old boxes that are rebooted come up with wrong routes to the point where none of their network services work. Some of these boxes had 4-6 network interfaces used plugged into different networks with specific routes for each network. reboot, and they are all deleted.

Re:

[RedHat Rocky]

Security fixes require reboots, period. Yes, Linux/UNIX is included, a kernel replacement means reboot.

Never mind best practice would be to schedule a reboot on a regular basis, not because it's necessary but to guarantee servers will come up correctly given system changes, patches, etc.

Java...

[loony]

OS patches are easy - we even built our own for patches for some obsolete unix flavors. The tzfile format is well documented and straight forward.
Our big issue is java... Whoever designed that piece of sh*t should be shot. They get the time information from the OS - so why not pull the TZ data from the OS too? But no - they rather implement it themselves... The result is beautiful. Oracle installed? You need an extra patch. Informix 10? Another patch. Websphere? Guess what - patch it separately! In the end, we had some boxes that needed 8 or more applications patched in addition to the OS.

Peter.

Re:

[Mr. Fahrenheit]

I agree with the java rant here. AFAIK, Oracle (possibly Informix, etc.) actually does get date/time information right from the OS, so traditionally (can Y2K be called a tradition?) has been a conundrum for the OS -- displaying Y2K dates required a patch, but otherwise things were pretty ok. ...BUT now that Java's being bundled into the distros because it's just so darn useful, patches to DB software bundles have to be released. With Oracle specifically, the best time to cram the DST patch into place migh

Re:

[Christopher_G_Lewis]

Yep - Java is going to bite us in the A$$.

Quick scan of some of our servers was showing between 5 & 10 Java.exe's, mostly in non standard locations. Some in user's home storage, some in our central binary shares. And *none* capable of handling the DST change.

The end result is that each server is going to have to be addressed *by hand* - no automated patching on this beast.

The bitch of it is that we're not only planning major work before March, but also next October - because there's a huge chance that

Re:

[Cheeze]

we're trying to decide if we want to upgrade java to the latest release or patch.

either is a horrible choice.

Re:

[Anonymous Coward]

Additional details regarding minimum JVM versions required to address the timezone changes:

- Solaris/Windows/Linux: 1.4.2_11
- HP-UX: 1.4.2.11
- AIX: 1.4.2 SR 5 20060420

- Solaris/Windows/Linux: 1.5.0_06
- HP-UX: 5.0.3
- AIX: 5.0 SR 1 20060310

References:
HP: http://www.hp.com/products1/unix/java/DST-US.html [hp.com]
Solaris/Windows/Linux: http://java.sun.com/developer/technicalArticles/In tl/USDST/ [sun.com]
AIX : http://www-1.ibm.com/support/docview.wss?uid=swg21 232128 [ibm.com]

Clock Companies

[erbbysam]

Clock companies everywhere aren't prepared for this. I work for one and they have to manually update all of the tower and post clocks that they have made which is in the thousands. When this last happened in the 70's there weren't embedded electronic clock systems. When daylight savings time came around you just got up on a ladder and spun the dial backwards. CBS had the best quote on this from there nightly news "do you love summer barbeque's and parties? then you'll love this" almost like they were sellin

Time is an artificial construct

[1_brown_mouse]

It has no meaning. This is confirmed by the fact that yahoos in a governing body think they can control it.

Each server and client has its own definition of time that has meaning to it. Seeking to establish hegemony over each definition is fascism at its worst. Every server and client can seek to be the same as others in of its own free will.

One day, at one time, all the clocks will be the same. At that moment, the Flying Spaghetti Monster will return in Glory. Ramen.

Until that day, time is nothing.

Incandescent vs CF bulbs

[chiller2]

There are way more lights than there are data centers, so if the government were serious about saving energy they could stop the production / import of incandescent light bulbs, or at least make them as financially unattractive as possible. Perhaps taxes on bulb sale and high import tariffs would do the trick. Link here [bbc.co.uk].

We should ban the numbers 13 and 911 too...

[anon mouse-cow-aard]

Out of deference to the events in 2001, the number 911 should be reserved for unique use (in North America) of the emergency services telephone number, it's use in all other contexts... 13 could be included in the ban to standardize current practices. Most high rises do not have a thirteenth floor, and Friday the 13th would cease to be a problem. No price, by law, for any item will ever be 13 or 911 dollars, except on march 13th (except when that would fall on a friday, in which case it would be a slip year), and September 11th, when those prices will be allowed. No use of the numbers 13 or 911 will be permitted in architectural or engineering diagrams of any kind, for fear offending those who lost loved ones on that terrible day.

The impact on counting should be very minor, as I personally lived in an apartment on 12B for many years, and there was no cost to this. A few if statements here and there. Sure, there are some complications,
Look, for example at the daylight savings time, how simple it is to understand that on some days of the year, there are 23 hours, (where there is no 3:12 am.) and on others, there are 25 hours (where there are two 3:12 am's.) but only in some places, sometimes, depending on what the local government says.

It is great to change how people count... dollars, dimensions, hours, to serve political or societal goals. It makes life better for everyone. Much simpler than changing prices or opening hours to serve them. All we need to do is pass a law, and change the way we count. Simple and practical so that no one has to keep track.

Re:

[PygmySurfer]

Out of deference to the events in 2001, the number 911 should be reserved for unique use (in North America) of the emergency services telephone number, it's use in all other contexts... 13 could be included in the ban to standardize current practices. Most high rises do not have a thirteenth floor, and Friday the 13th would cease to be a problem.

Thanks, asshole.. my birthday is on the 13th :) I was born on a Friday, too..

Does this mean I'll be 28 forever?

Re:

[anon mouse-cow-aard]

Well, there you see you are demonstrating the problem afflicting so many of our youth today.
If the proposal is accepted, no-one will have your problem in the future. While preventing problems
for future generations, we need to be sensitive to those who face challenges such as yours today. those who are most unfortunately afflicted with being born on the day between 12 and 14 could refer to their birth day as the '12B' of a month, and have the option of celebrating on either the 12th or 14th. In the modern

Re:

[PygmySurfer]

as long as I get some kind of government subsidy to help deal with my affliction, I'm all for it.

Re:

[anon mouse-cow-aard]

you just check off "numerically challenged" on the form. We will probably add a new category to
the affirmative action directives.

Just set your TZ

[krakrjak]

Luckily in *nix systems that support the TZ shell variable (all POSIX systems) you have a way to make it behave as you wish irregardless of special timezone file sets. Just set your TZ variable using the long form:

std offset dst [offset],start[/time],end[/time]

Example: EST+5EDT,M4.1.0/2,M10.5.0/2

In the example EST is set to have the normal offset from UTC of 5 hours; since this is west of the prime meridian, the sign is positive. Summer time begins on the first Sunday in April at 2:00am, and ends on the la

Indiana had to deal with this already...

[fwittekind]

Indiana used to not honor DST, now we do :(

Not real fun change to have to deal with. Especially on the MS machines. I don't believe MS issued any patches for the change, just a post on how to change your timezone setting manually (which is all fine and good, except for applications that store the timezone with entries)

DIY Time Zone configuration

[jrifkin]

Under Unix, you could configure time zone changes yourself with zic.

For example, the following input to zic will create the four zone info files US/Eastern, US/Central, US/Mountain and US/Pacific. These will be under your ZONEINFO directory (mine is /usr/share/zoneinfo).

# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule DST 2007 2017 - Mar Sun>=8 2:00 1:00 D
Rule DST 2007 2017 - Nov Sun<=7 2:00 0 S

#Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL]
Zone US/Eastern -5:00 DST E%sT
Zone US/Central -6:00 DST C%sT
Zone US/Mountain -7:00 DST M%sT
Zone US/Pacific -8:00 DST P%sT

The input above configures the time change for the years 2007 to 2017 (an arbitrary end year) so that DST starts the second Sunday in March, and ends the first Sunday in November, as specified in the Energy Policy Act of 2005 [wikipedia.org].

You can test your resulting files using the zdump command, like this

> zdump US/Eastern
> zdump -v US/Eastern

You might have to refresh links to these new files, check /etc/localtime.

Disclaimer: I'm not a time zone expert, so don't take this on faith.

Bunch of whiners

[JamesP]

In Brazil DST rules changes _every year_. Try dealing with THAT!

The end result: people change it manually... And as they said, servers use UMT, so...

ZIC

[MicklePickle]

and Sun will not be supporting Solaris 7 and older.
Pretty much all UNIXes use text based TZ information, or tools that create
the correct information, (IE zic). Patches shouldn't be an issue. During the Y2K
fiasco^H^H^H^H^H^Hchanges all I did for my 150 odd servers is recompile my own
zoneinfo file and distribute via rsync.

Re:

[bshellenberg]

And the energy use of SUVs doesn't even hit a percentage point of the energy used to power trains, planes, busses, transport trucks, ocean liners or even the tankers that move the oil around the world. Don't let your land-lovin-tree-huggin hatred for the SUV blind you from the fact that there are MUCH bigger fish to fry. btw: My SUV gets 28 mpg. The minivan it replaced got 22 mpg.

Re:

[lizrd]

Problem is that sometimes that kind of shit backfires. SUVs are popular because the CAFE regulations effectively banned large cars. As a result, people who would otherwise have purchased a large car now purchase a small truck to use as a car.