Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Power User Journal

Is Daylight Saving Shift Really Worth It? 652

Krishna Dagli writes "Two Ph.D. students at the University of California at Berkeley say that Daylight Saving Shift will not do any good or create any energy savings. We are already spending money for software upgrades in the name of saving energy and after reading following article I wonder has congress really studied the impact of DST shift? " I also read some back story on the concept; OTOH, I found TiVo's suggestions that I manually change everything on my Series 1 device to be somewhat...insulting.
This discussion has been archived. No new comments can be posted.

Is Daylight Saving Shift Really Worth It?

Comments Filter:
  • by Vengeance ( 46019 ) on Monday March 12, 2007 @08:45AM (#18314873)
    I already work 7:30 to 3:30. Having DST at all is really just a nuisance to me.
  • Issues so far (Score:4, Informative)

    by OriginalArlen ( 726444 ) on Monday March 12, 2007 @08:45AM (#18314879)
    According to the SANS Incident Handler's Diary [sans.org], various issues have been reported in Cisco VOIP phones, Blackberrys, Veritas aka Symantec BackupExec, and Watchguard firewalls.
  • The letter from TiVo (Score:3, Informative)

    by AtariDatacenter ( 31657 ) on Monday March 12, 2007 @09:06AM (#18315113)
    Here is what TiVo sent me. The Thursday (Mar 8) before DST. Thanks for the warning!

    Dear TiVo Subscriber,

    As Daylight Saving Time commences three weeks early this year, we
    thought we'd beat the clock to let you know how this unusual schedule might
    affect recordings on your TiVo(r) Series1 DVR. (Hint: Chances are
    slim.)

    While the TiVo service will continue to automatically record your
    Season Pass(tm) programs and WishList(r) searches at the correct airtimes
    without incident, there are two things to note:

    1) For the three weeks that follow the new Daylight Saving Time start
    date (March 11), your Series1 TiVo(r) DVR may display the incorrect
    time.

    Again, to be clear, this is only a cosmetic issue and should not affect
    your Season Pass(tm) and WishList(r) recordings.

    2) If you have any MANUAL recordings scheduled between March 11 and
    April 1, you
    will need to adjust those recordings as appropriate. Here's how:

    - From TiVo Central, select Pick Programs to Record, then To Do List.

    - Locate your Manual Recording (by channel, date, time) and adjust
    accordingly. For example, if you have a daily manual recording from 8:00 am

    - 9:00 am, you will need to change it to 7:00 am - 8:00 am on March 11.
    (Quick Tip: If there are no recordings in this list preceded by the
    word "Manual", there's nothing further you need to do.)

    - On April 1 be sure to change it back to its actual time, i.e., 8:00
    am - 9:00 am.

    For more details, please visit www.tivo.com/dst

    Thanks for being a TiVo subscriber and here's to a beautiful spring!

    - Your friends at TiVo

    TiVo, Season Pass(TM), and WishList® are trademarks or registered
    trademarks of TiVo Inc's subsidiaries. ©2007 TiVo Inc. 2160 Gold Street Alviso,
    CA 95002-2160. All rights reserved. Please feel free to review our
    Privacy Policy.
  • by Prowler50mil ( 990067 ) on Monday March 12, 2007 @09:29AM (#18315399)
    Even if the DST dates are not hard-coded there is still the problem of upgrading all the units out in the field.
  • by JLennox ( 942693 ) on Monday March 12, 2007 @09:34AM (#18315455)
    They're not built in random directions, the roads are. The house simply faces the road.
  • by davechen ( 247143 ) on Monday March 12, 2007 @09:48AM (#18315653) Homepage
    Yup, I heard the story on NPR. It was an interview with Michael Downing, author of the book "Spring Forward: The Annual Madness of Daylight Savings Time". He said there's not much energy savings, but more shopping because of DST.

    http://www.npr.org/templates/story/story.php?story Id=7779869 [npr.org]
  • Re:More driving? (Score:3, Informative)

    by hb253 ( 764272 ) on Monday March 12, 2007 @09:50AM (#18315677)
    We will get an increase in gasoline price regardless of DST. This is because the refineries have to switch to summer-formula gasoline which is more expensive to produce.
  • by DragonHawk ( 21256 ) on Monday March 12, 2007 @09:59AM (#18315809) Homepage Journal
    "This change in DST was definitely worth it, if only for the benefit of forcing embedded systems designers to remember to not hard-code DST dates into their code."

    I'd buy into that if there was any evidence that programmers ever learned from their mistakes. But in my experience, the opposite is true: We keep making the same damn mistakes, over and over.

    Hell, look at buffer overflows. Still the #1 cause of security bugs. It's not like bounds checking is a radically new idea.

    If you're of a historical mind, read The Mythical Man-Month, by Fred Brooks. It's illuminating to discover that we are still struggling with the same problems today that they were dealing with in 1960.
  • by chrwei ( 771689 ) on Monday March 12, 2007 @10:17AM (#18316081)
    Instead of a government mandate to change the clocks, why not use the same mandate to make it so that the 8-5 be changed to 7-4? I don't really see the difference except that no one has to fuck with all their clocks.
  • by Megane ( 129182 ) on Monday March 12, 2007 @10:17AM (#18316087)

    Time zone specific calculations are on the client end, as all NTP sources give time in UST.

    Fortunately, WWV includes a DST flag so that at least those so-called "atomic clocks" (actually radio clocks) automatically changed at the right time.

  • by Hoi Polloi ( 522990 ) on Monday March 12, 2007 @10:20AM (#18316121) Journal
    "I take a camping trip at the end of March every year and it will be SO nice to have that extra hour of daylight to get camp setup, cook dinner, and enjoy the park."

    When I camp I get up with the sun and set up camp around sunset regardless of what the clock says. DST doesn't give you more daylight.
  • by Waffle Iron ( 339739 ) on Monday March 12, 2007 @10:54AM (#18316567)

    Not at all. The last change in the USA was 20 years ago.

    In the US, it was changed federally in 1918, 1920, 1942, 1945, 1966, 1974, 1975, 1985, 1986 and 2007. That averages out to about once per decade. Up until 1966, many individual states also fiddled with the times. Even today, states are allowed to opt in and out of DST altogether, and Indiana just recently changed its rules.

  • The coldest hour (Score:4, Informative)

    by wytcld ( 179112 ) on Monday March 12, 2007 @11:10AM (#18316761) Homepage
    Here's the real loss:

    If you live in the northern US and are doing the responsible thing and turning your central heating down overnight, then getting up an hour earlier means you're turning the heat back up earlier. Why is this wasteful? Because on sunny days in March there's significant solar gain once the sun's up. In my house that can be enough that the heat doesn't even need to be turned on in the morning - unless we get up too early.

    In the evening, both the house and the outside environment lose their heat relatively slowly. The darkest hour isn't literally just before the dawn, but the coldest hour is. It's much better to spend the coldest hour under the covers - from an energy use point of view - than to get up during it or right on its tail and turn the furnace up to compensate.

    Of course, if the government just looks at electrical use, this may not show in areas that don't primarily use electric heat. The increase in oil and natural gas use though, from this idiocy, will be real and significant.
  • Re:News Flash (Score:3, Informative)

    by ivan256 ( 17499 ) on Monday March 12, 2007 @11:18AM (#18316867)
    That's a pretty snarky comment.

    There are very very few businesses where start / finish times really matter, though there are more where they are enforced. Service oriented you say? Contractors (carpenters, electricians, plumbers, sanitation, maintenance) not only can choose their hours as they please (with the exception of emergency calls), but the frequently do. Consumer banking keeps retail hours, so you need to be there when the storefront opens, but they have no regard for their customer's schedules; after all, the term "Banker's Hours" exists for a reason. Construction and manufacturing require their workers to keep strict hours, but there is no reason they couldn't change those hours throughout the year to work during daylight...

    How many jobs have you had? And I'm not talking employers... How many different jobs have you worked? I'd venture to guess that the answer is one or two.
  • by Andrewkov ( 140579 ) on Monday March 12, 2007 @11:52AM (#18317349)
    It takes energy to have the headlights on. That energy comes from burning gas. A car would get slightly better mileage when driving with the headlights off.

    However it is a bad example, I would keep the headlights on for safety reasons anyway, and most (if not all) newer cars have daylight running lights which are always on.
  • by IDontAgreeWithYou ( 829067 ) on Monday March 12, 2007 @11:53AM (#18317365)

    On /. we obey the laws of thermodynamics. You are absolutely, 100% using more energy running your headlights in your car. ALL of the energy used by your car comes from the gasoline that you put into it (with the small exception of any charge already in the battery when it was installed). Therefore, you are using more gasoline with your headlights on than you would if they were off. It might be too small to easily measure, but the difference is there.

    If you want some tangible proof of this, find a small hand cranked generator and hook it up to a blinking light bulb. You can actually feel the crank get harder to turn when the light is lit and become easier when it goes off. So the more electricity used by your car, the more gasoline you use or your battery goes dead.

  • Usable daylight. (Score:3, Informative)

    by The Monster ( 227884 ) on Monday March 12, 2007 @12:02PM (#18317467) Homepage

    I'm rather fond of my 8-5 world including more daylight after I get off of work.
    Before we had these time pieces, people got up at sunrise. Over the course of the six months between solstices, the change would be a minute a day at most in the temperate zone. This gradual adjustment went away when we started using sundials, which based the time of day on noon instead of sunrise.

    Then we got clocks, which came in handy for things like train schedules. The railroads had a problem. When an Atchison, Topeka, & Santa Fe train left the former at noon, it was still 11:57:46 in the second city, and 11:16:41 in the latter. The difference caused all sorts of problems. So the AT&SF might decide to standardize on Topeka Time, while the Union Pacific would choose Omaha, which would be a minute and 36 seconds behind Topeka, complicating matters where passengers or cargo had to change trains from one line to another.

    So one of the railroad men came up with the bright idea of a standard time system for the whole country, where just the hour would differ between 'zones' approximiately 15 degrees of longitude in width. Since astronomers used the meridian of the Greenwich Observatory as '0', that would put Atchison, Topeka, and Omaha all well within 7.5 degrees of 90W (just east of St. Louis), while Santa Fe was just west of the 105W meridian, and would have its clocks set to an hour earlier.

    In practice, the actual boundaries have tended to skew westward, so that even in the Winter, astronomical noon is after 12:00 Standard Time, leaving more daylight after people get off work in the afternoon. The boundary between the Central (90W) and Mountain (105W) time zones actually touches the 105W meridian in TX, and Saskatchewan effectively pushes it further west by declaring that it's on permanent DST (which is a contradiction in terms, and is therefore rendered on maps as being inside the CTZ rather than permanent MDT)!

    Of course, a lot of Slashdotters rarely the light of day, so to them it's all a pointless exercise.

  • by profplump ( 309017 ) <zach-slashjunk@kotlarek.com> on Monday March 12, 2007 @12:20PM (#18317669)
    Now if only they used it. I've got an analog radio clock that doesn't even display the date, but for some reason they decided to read the date bits and do some calendar calculations (or hard code the next X years of DST dates) to calculate DST rather than reading the flag.

    I don't understand why you wouldn't use the flag -- it seems easier to just read the flag than to calculate the start/stop dates. There's even a countdown so you can miss several days of syncing before the switch and still know when it should happen. Apparently not all clock designers share my hatred for calendar calculations.

    FYI: Common radio clocks use the 60kHz WWVB signal not the 2.5-20 MHz WWV signals. They both contain the digital timecode information, but WWV and WWVH also include frequency information (440 Hz, 500 Hz, 600 Hz, 1000 Hz and 1500 Hz beeps) and vocal timestamps, and reports about the weather, GPS health, and solar/radio conditions. In general WWV/WWVH are intended for manual use (all the time information is available in a format useful to human ears) and use outside the WWVB range, but WWVB is more accurate where available (better straight-line propagation) and less complicated to decode electronically due to the extremely low bit rate (a standard serial port can decode directly from an AM amp).
  • Re:Is it worth it? (Score:3, Informative)

    by walt-sjc ( 145127 ) on Monday March 12, 2007 @02:21PM (#18319689)
    The "lost productivity" line is nebulous at best - his activity was redirected from other projects, for sure, but the deadlines on those projects remained the same. If those projects were important and had tight deadlines, Bill would have not been moved to DST work, and the people impacted would have been warned to update their clocks manually...

    I think you underestimate just how large / bad the problem was/is. In larger companies it is a huge effort. You seem to think that deadlines for other projects were not changed, or that "Bill" simply has to work more hours. Nothing can be further from the truth. Maybe in your company where management doesn't track what their employees are doing and the status of their projects, but not here.

    It wasn't just OS patches, but many many applications, network devices / appliances, etc. had to be patched too. Some legacy systems were worse as their as were no patches, so systems had to be updated manually. Some are just plain broken and there is no workaround. In larger companies, this usually means that many teams from many departments were involved. It wasn't just a "oh yeah, gotta change the time early" thing, it was a coordinated, planned effort, with testing, documentation, etc.
  • Re:Is it worth it? (Score:3, Informative)

    by Maxo-Texas ( 864189 ) on Monday March 12, 2007 @02:45PM (#18320173)
    In our case, it involved about 40 people and about 1200 hours were billed.
    Tens of thousands of machines patched.
    Hundreds of pieces of software considered.

    Real projects were pushed back 4-6 weeks for this non-work.

    Agree about "a day's work for a day's pay" angle you have. In fact, it's how we work around here-- any given day you can be off one project and on another random one that is now higher priority.

    But, I'm pretty sure this cost us at least 2-3 weeks of real productivity.
  • Re:Is it worth it? (Score:3, Informative)

    by treat ( 84622 ) on Monday March 12, 2007 @07:19PM (#18324503)
    Unofficial estimates claim that costs due to the DST change well exceed a billion dollars TODAY which is more than the theoretical energy savings added up over 10 years.

    Where I work, we have a reasonably fresh environment. Better than any other significantly sized business that I am familiar with, mostly due to several rounds of cleanups. Everyone aware of the costs below was LAUGHING about how we are so much better off than a few bigger businesses in the industry who's stories we heard. Let's consider the cost associated with the DST switch:

    • Sysadmin time patching supported Solaris machines - the patch requires a reboot (yes, really), and it breaks the system until the reboot so you must reboot right away. Sometimes you have to install the recommended patch set, which could break something. I estimate about an average of 10 minutes each for the sysadmin, plus an average of 3 minutes for application guys to check the system out. 13 minutes * 500 machines = 6500 man-minutes.
    • Sysadmin time dealing with unsupported Solaris machines - Sun charges $400 per machine for the patch for Solaris 7 and older. We had 50 such machines. We decommissioned 40 and paid for 10. It took probably 1 man-hour per machine decommissioned, not counting hardware and networking effort. Some were replaced with new hardware, but I won't count that cost. 40 man-hours plus $4000.
    • Sysadmin time patching unsupported Linux machines - pretty simple actually, 1 man-hour for every machine.
    • Sysadmin time patching supported Linux machines - seemed simple at first, updating the tzdata package (1 man-hour for every machine, includes phased rollout and communication with app teams). Turns out that there was a bug in Redhat Enterprise 3, updaing the package does not update /etc/localtime. Another bug we noticed -today-, cron does not reload /etc/localtime like every other application. Add 5 man-hours debugging the latter two problems and cleaning up the repercussions of the cron problem. Add $10,000 in lost profit because of customer issues caused by cron failing to start applications at the right time this morning.
    • Sysadmin and app developer time in upgrading every Java instance everywhere, verifying that no one is still using an old one - 40 hours for sysadmins, 200 hours for app guys. We use a lot of Java.
    • We were hit by the Java bug before Sun announced it Thursday (http://sunsolve.sun.com/search/document.do?assetk ey=1-26-102836-1&searchclause=). They were aware of it back in September, but only made the announcement at the last minute after it started causing the widespread problems that they were warned about in September. Time spent debugging and cleaning up the mess, probably 12 man-hours. Cost due to messed up transactions is a low estimate of $50,000.
    • Another 40 man-hours spent by everyone re-testing and re-checking their applications for the newly discovered bug. Sun's fix was so insane sounding and was so last-minute that we could not just deploy it.
    • Other miscellaneous devices, networking gear, console servers. Patching databases. 40 man-hours.

    I count 487 man-hours plus $64000 in direct costs and lost profit. Figure an average employee cost of $100/hr. $112,700 in total costs. Wow!

    I'm still really, really confident that we had it better than most.

"Experience has proved that some people indeed know everything." -- Russell Baker

Working...