Slashdot Mirror
Impact of Daylight Savings Time Changes?
jason718 writes "With the pending changes to U.S. Daylight Savings Time, what impact will those changes have to existing systems and their applications? Are some operating systems more open than others with regard to the configuration of Daylight Savings Time start and end dates, or will we need yet another update or patch to modify the internal calendar?"
With over 800 comments, I thought that's enough to get an idea of its impact and suggestions to deal with it.
Rock that crushes, Paper & Scissors that don't matter.
(Until we follow you guys)
We've always been at war with Eurasia.
Thank goodness Indiana is going to implement DST statewide next year, though - I work for a Swedish company in Indianapolis, and you wouldn't believe how many teleconferences get screwed up because the rest of the world changed their clocks and Indiana didn't...
Stop by my site where I write about ERP systems & more
An article from Colorado's legislature suggests that the primary complaint from farmers is that "most agricultural activities are based on daylight hours as opposed to clock hours, and crops and livestock maintain their schedules regardless of the time reflected on the clock."
Because the farmers and their families would still have to work with their product during certain margins of the day to accomdate the plants, they would have to readjust their schedules to do non-farm things like shop for food, meet with a bank, etc.
In the case of agribusiness, they would have to readjust the schedules of their employees.
It's Daylight Saving Time, not Daylight Savings Time.
As long the operating system can handle both local time and Coordinated Universal Time, it should not be any problem. If the program saves every time in UTC, and when displayed, convert it to local time, the user should not need to be worried. As a European citizen we all have DST, and we manage easly, so why shouldn't those in the US manage too?
------- In the end there are no begining
Of course, the countries of the world that do change their clocks don't change their clocks at the same time. The EU starts DST on the last Sunday of March whereas we (currently) start ours on the first Sunday of April. Currently, we both end ours on the last Sunday of October.
If we're going to change how we handle DST, I'd recommend that we match the EU. I know that the idea of following the EU's lead is anathema to many of us, but hey, it's a small sacrifice and shows that we're willing to make compromises every so often.
Ben Hocking
Need a professional organizer?
Cisco devices, both IOS and CatOS based, use the 'summertime' command to compensate for daylight saving time (example [cisco.com]). This means that a change in the DST setup would force you to upgrade code.
Or at least it would force you to study the command reference a bit better, and find the second optional form of the command that allows you to specify the beginning and end of summertime.
That would mean you require only a configuration change, and not a code upgrade.
But of course you would need to read the manual...
Relax -- your investment in atomic clocks (really radio-controlled) is safe :) They get DST from the master clock already.
All of the radio-controlled or "atomic" clocks work on the same idea -- they receive a time signal from a low-frequency transmitter (60kHz in the US). The device will typically set an internal quartz clock from the received time code. The time reference signal is strongest at night, so it's typical for these clocks to set themselves at 2 or 3 am (local time). Some newer designs will set whenever the signal strength is high enough for a good read. This redundancy makes for a very reliable device.
The time code contains, among other things, a flag indicating whether DST is in effect. So -- when (if?) this change to the DST rules goes into effect, the folks who run the transmitter will change the flag at the proper moment, and the next time your clock reads the signal, et viola! it reads DST.
The radio station broadcasting the time code in the US is WWVB, and it is managed by NIST. The WWBV system is really an elegant design, involving a wonderful mixture of old and new technology. Check it out:
http://tf.nist.gov/stations/wwvb.htm
By the way, there are 4 other time zones east of US Eastern. The Atlantic time zone, for example applies in Nova Scotia. There are also similar time reference broadcasts in the EU, Russia, and Australia. There might also be one in China - but I've never needed to look that one up. I'm sure that will change one day soon.
Who? Whom? It might help your career if you know the difference.
http://www.ku.edu/~edit/whom.html
Who refers to a subject, whom refers to an object.
You should have said: "Who is fooling whom?"
I offer this tip merely to help you advance your career, not to be a national socialist.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
"If you want to go to work an hour earlier, just go to work an hour earlier."
Except there's a whole trickle-down effect from the federal agencies that observe things like daylight saving time. It's a lot like federal holidays; sure, you can be open for business, but the more your business relies on, say, transactions at the Federal Reserve, the less work you're going to be doing for that hour between when you open and when the Federal Reserve opens. So far as commerce relies on groups of people coming together, the only way you can effectivley do something like this is all or none, otherwise the concept of standards becomes meaningless.
"Noon should always be when the sun is directly over my time-zone."
I'm surprised there isn't some sort of "bad atronomy" page on this.
First off, time zones are not defined by two meridians. They start off that way, but then they move with respect to political boundaries in an attempt to keep states (or at least counties) synchronized. Otherwise Airzona would be split right down the middle (Arizona goes from about 109 W to 114 W, and the line "should" be at 112.5 W)
Secondly, the length of time between two consecutive noons is never 86,400 seconds. The reason we developed mechanical timekeepers and then ultimately defined our length of time on something that has nothing to do with astronomy is that the sun is inconsistant. The earth's orbit is not circular, the earth's speed in that orbit is not constant, and the result is that, over regular 86.4 ks cycles, the sun traces a figure-eight over the course of a year.
On 2005 October 30, when the US and the EU both go back to standard time zone, the sun will be directly over New Orleans (almost exactly 90 degrees west of Greenwich) at about 11:44 AM Central Standard Time. On Groundhog's Day next year, after racing past perihelion, "noon" will be 12:14 PM.
"Change the start time instead of the clocks"
That would defeat the purpose of having a standard schedule to begin with. People and other businesses need to plan around when you intend to operate, and a system where everybody's schedule drifts from time to time leads to confusion at best. It's better to change the standard frame of reference than to try to alter behavior within that frame of reference.
If anything, what you're proposing more resembles the "logic" of setting your personal alarm clock ten mintues later than Daylight Saving Time. Both examples involve deviating from an accepted standard.
"Do it gradually, the way available light changes gradually."
First, if you're going to do it based on fractions of hours, why bother having time zones of integer hour differences to begin with? Why bother with time zones at all?
Secondly, the amount of daylight during a day and the change of that amount between two consecutive days varies with latitude, not longitude. Just because you are able to describe the change as "gradual" in Arizona does not mean it is "gradual" in New York or Oregon. Daylight Saving Time makes less sense the closer you are to the Equator because there is less change in sunlight over the course of the year (how the Equator got its name), which is why Hawaii, in the tropics, doesn't follow it. However, even without leaving the contiguous 48, we can look at the Car Talk brothers in Massachusetts and their half-joking suggestion of going ahead two hours because, even with Daylight Saving Time, the sun was still rising at 5 AM EDT (a/k/a 4 AM EST).
According to the US Naval Observatory sunrise in Boston on 2005 June 21 was 5:08 EDT (4:08 EST), with the sun being above the horizon for about 15.5 hours for that day.
" That way you don't fuck up people's sleep cycles either."
Not changing clocks seems to
You don't need to reboot.
If you are not sure about cron rereading the timezone:
- read the man page
- ask someone who knows (mailinglist?)
If in doubt, just do a "/etc/init.d/crond restart"
that should do the trick.
we need an "-1 Plain wrong" moderation option!
Before you start doing the LED lighting conversion look into high energy capacitors (so-called "Supercaps"). I haven't run the numbers, but my guess is they aren't at a good price point yet. A design built around them would have the advantage of zero maintenance, and a working lifespan of about 10 years.