Slashdot Mirror
Prepared for Next Year's Time Change?
wohlford puts forth this query: "Next year, daylight saving time will be extended another four weeks. Slashdot has covered the time change proposal and its estimated impact, already. Since then it has been signed into law. Looking around on the Net I don't see anyone taking this seriously. Will this become the next tech doomsday or just another joke like Y2K?"
Personally, I hate daylight savings time and see no need for it. Just get up earlier or later as needed. Further, I don't see why we can't just all use GMT. So you get up at 08:00 and I get up at 21:00, big deal.
Except that it'll get its time as GMT and it still has to make the decision about how much to offset it. A simple rules update for linux and windows should take care of a lot of the problem- but many custom apps will have to be altered or potentially produce incorrect times. I imagine .NET will help some of this in the windows world as it'll just use the underlying routines, which can be updated once by an MS update.
I imagine it'll be a headache, but things generally wont come to a screeching halt.
Go to hell. A lot of people put a lot of work into resolving a real problem. We'd sure as hell have heard about it if we hadn't.
One of those damned if you do, damned if you don't things I guess.
R: That voice. Where have I heard that voice before? B: In about 365 other episodes. But I don't know who it is either.
What is your solution to 03:14:07 January 19, 2038 UTC?
You are being MICROattacked, from various angles, in a SOFT manner.
Indiana switched this year.
Indiana has historically had 2 timezones. Part of it was Eastern, and part of it didn't change. They changed this year to all be on Eastern time. (wrong choice) A lot of our customer read that news and changed the timezone on their servers to Eastern. All of their historical data got screwed up.
The REAL fix was to apply an OS patch and keep in the same Time-zone they've been in. The OS patch changed that TZ file to understand that previous to a certain date the timezone behaved differently. That's going to need to happend for all the timezone definition files with this new law.
Unfortunately...that means even if they DID get rid of daylight savings time, the whole history of how it has changed through the ages would need to be contained within those TZ definitions.
Incidentally, changing the timezone value on a server is actually one of the worst things you can do with for our particular software.
--Welcome to the Realm of the Hawke--
It's only the US, who cares?
Curiosity was framed; ignorance killed the cat. -- Author unknown
64-bit computers. :)
Please, for the good of Humanity, vote Obama.
Changes to daylight savings time start and end times are hardly a big deal. In Australia it happens all the time. Just this year, daylight savings time was extended by a week in March, and no planes fell out of the sky. About half the computers I used updated and showed the real time, and the other half (including some apparently independent clocks that were set by some remote mechanism) switched back early and were an hour slow. Everyone coped just fine.
Most people know what hour it is anyway, so it's only important computer systems that matter. And if Microsoft can have a patch for two states and one territory in a relatively small country, then they can have a patch for the vast majority of their home country...
Absolutely nothing to worry about. Just enjoy the extra daylight in the evening!
Look out!
03:14:08 January 19, 2038 UTC, shortly followed by 03:14:09 January 19, 2038 UTC.
Honestly, there's no good excuse for anyone not using at least 64-bit integers to represent unix time these days, yes even on 32-bit architectures.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
I want a patch for my operating system that will automatically let me know when Congress does something stupid...
"Not an actor, but he plays one on TV."
I work for one of the "dying breed" of Daytime ONLY AM radio stations. Because of the effects of the sun on the ionosphere, Medium Wave (AM Broadcast) signals bounce off of a layer the ionosphere at night, and are absorbed by a different layer which forms during daylight hours. As a result, a number of stations were allowed to operate only during daylight, when the dominating station on that frequency would not be affected.
Case-in-point, WFIF where I work. WTOP (now WTWP) has operated on 1500Khz for many decades. They are the dominant station on that frequency for the entire Eastern half of the US. (At night, you can hear them from Maine to Florida. Been there, done it.) They are located in Washington, DC. WFIF was licensed to operate on that frequency in 1965, as a daylight-only station. Thus, every day at the FCC-established "legal sunset", we must sign off. We cannot return to the air until the FCC-defined "legal sunrise". (The FCC defines the sunrise/set times for each month, based on an average, so the actual sign-on/off times remain the same through each month.)
Now we throw the DST/Standard time curveball into this. Because the sun doesn't change, only our clocks do, this affects when we can sign-on and off, and it affects our program schedule.
Example- under the present system, in October, during DST, we sign-on at 7am and off at 6:30pm. When we change to Standard time on that last Sunday, we get to sign-on at 6am and off at 5:30pm until we hit November. In November, we sign-on at 6:45, and off at 5pm.
Now throw this new monkey wrench into the works...
We will no longer have *any* Standard time operation in October, because it won't kick-in until November... so, that means we won't be able to sign-on until 7:45am! (Right now, our latest sign-on is 7:15am in December & January.) That's pretty darned late in the morning to be signing-on! Once Standard time takes effect, we'd be back to where we are, now: 6:45am to 5pm.
In March of '07, we're going to have another curveball to throw at our audience... we will have been signing-on at 6am for the first few weeks of March. Then the clocks will be changed. Now, we won't be able to sign-on until 7am! Programming that had already re-established itself with our audience will go on yet another hiatus, before returning in April. (The early morning music program already goes away in October & Dec/Jan due to the later sign-on.)
So, as you can see, there are some radio stations and listeners that are going to be ***VERY*** inconvenienced by this mess.
We won't even go into the issue of how many computers are out there still running Windows 98SE, which won't be getting any help from Papa Bill to patch it's internal time-shifting routines. I am hoping for a 3'rd party solution... but won't hold my breath. Since we still have a fair number of perfectly functional Win98SE boxes running, we'll just have to disable the automatic time-shift routines, and do it manually.
Willie...
typedef int64_t time_t;
Hmm, that should work fine.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
Most atomic clocks don't have rules for when to switch to DST. They just use the code from the time from NIST, which includes a flag to indicate whether DST is in effect or not. As long as NIST changes when they include the DST flag, Atomic clocks should switch to DST on the correct day.
Why on earth does the US have a law on when should a bar close. I used to own a bar with some friends and would close it when we saw fit. Usually between 3 and 5 am. The "land of the free" sure seem less "freer" each time i look.