# Daylight Saving Time



## djburger (Jan 12, 2007)

Will a patch have to be downloaded to handle the change in the timing of daylight saving time for the R15 or does it get the time from the sky. Don't really care about the time on my other receivers but would like this one to record on time.

thanks


----------



## carl6 (Nov 16, 2005)

Not sure if it will need a software upgrade or not, but if it does, that should happen automatically prior to the necessary date, and you shouldn't have to worry about it.

Carl


----------



## wbmccarty (Apr 28, 2006)

OTOH, use of the word _should_ with respect to the R-15 entails considerable risk of inaccuracy.  I do hope that you're right, Carl.

Cheers,


----------



## rlambert7 (Feb 7, 2006)

djburger said:


> Will a patch have to be downloaded to handle the change in the timing of daylight saving time...


I just saw in a newsletter to which I subcribe that there is a patch for MS Windows XP regarding the modified DST time changes. I downloaded it, and tried to run it. Got a message something to the effect that it could not run because there was some table(?) that was already newer than the one it wanted to install . I suspect that is due to the the fact that I have automatic updates enabled on my PCs, so they were patched a while ago.

I sort of figured it would be some sort of table. So, if it is needed at all on the DTV receivers, it probably would be something simple like that. However, I do hope you are right, Carl, in wondering if it is needed at all. At this point, if an upgrade is needed, and, if the rollout time for the upgrade takes as long as it typically has in the past, all lot of folks are going to "miss the boat".


----------



## dodge boy (Mar 31, 2006)

I am sure that it gets it's time info from the Satellite, hence the auto detect featur in the auto setup, just like a cell phone gets it's time from a signal in the satellite.


----------



## rlambert7 (Feb 7, 2006)

dodge boy said:


> I am sure that it gets it's time info from the Satellite, hence the auto detect featur in the auto setup, just like a cell phone gets it's time from a signal in the satellite.


That's what I believe, and hope, as well. Since most system's times are referenced to GMT, and then just display "local time" based on the timezone offset from GMT and DST vs "standard time", there would have to be something in the time packets that said something like, "DST is now in effect", so the autodetect feature would have something work with.

I'm "betting" that a next version of the software is not going to be ready by March 11 (or at least I won't have it by then), but that the times on the DTV satellite receivers will be OK.


----------



## qwerty (Feb 19, 2006)

dodge boy said:


> I... just like a cell phone gets it's time from a signal in the satellite.


Cell phones get their time from satellites?


----------



## Earl Bonovich (Nov 15, 2005)

FYI - You can also see the DST adjustments in the Guide.

2am doesn't exist on March 11th


----------



## psweig (Feb 4, 2006)

C'mon you guys. Haven't you had your DVR through at least one DST adjustment either off or on??


----------



## Clint Lamor (Nov 15, 2005)

I think the major concern is DST is different this year then it has been in years past.


----------



## jpl (Jul 9, 2006)

Clint Lamor said:


> I think the major concern is DST is different this year then it has been in years past.


That's correct. Not only does it start earlier, but ends later as well. It was done by Congressional action. The question is not whether these systems can handle a shift in time, but whether they can handle the change in the start and end of DST. I believe in the past DST started in April (always at the same point in the month) and ended in October (on the last weekend of the month). Now it extend from March til November. If systems are designed to change their times on those (old) specific dates, then this change in the start/end of DST will have an impact. Meaning, if the R15 is coded to change on the last Sunday in October, then when the shift doesn't happen on that weekend this year, it's gonna screw everything up.


----------



## Earl Bonovich (Nov 15, 2005)

But that is the reason for my post in this thread.

The R15 *IS* coded to handle the new "rules" for DST
(NOTE: so is the HR20)


----------



## jpl (Jul 9, 2006)

Earl Bonovich said:


> But that is the reason for my post in this thread.
> 
> The R15 *IS* coded to handle the new "rules" for DST
> (NOTE: so is the HR20)


Sorry... didn't see your posting when I wrote mine.


----------



## psweig (Feb 4, 2006)

What I don't understand is why would a software patch be needed? I have a cheap atomic clock that just checks the GMT time, whatever day it is. To hard code DST is certainly poor programming.


----------



## jpl (Jul 9, 2006)

psweig said:


> What I don't understand is why would a software patch be needed? I have a cheap atomic clock that just checks the GMT time, whatever day it is. To hard code DST is certainly poor programming.


I don't think that's a correct analogy. GMT doesn't shift for DST. So your clock is most likely doing a conversion internally, or there's some external trigger that's telling it to shift by an additional hour. Or it could be getting a beacon, nightly, that tells it the current time. Either way, there's s/w somewhere that's making that shift for DST happen. While I would generally agree that assumptions hard-coded in systems like this are symptoms of bad coding practices, you have to draw the line somewhere. I would have said that the calculation for DST would have been a safe thing to assume in the code. In other words, for years the day and time at which the clock changes has been fixed - it's like assuming that Thanksgiving will always happen on the last Thursday of November, or election day will always be on the Tuesday following the first Monday in November. Can those change? Sure... but what's the likelihood that they will? Only Congress could be stupid enough to believe that making a change like to DST like this is a good idea.

What would have really been a bad practice, though, is if DirecTV didn't bother to adjust for it. They made a, not unreasonable, assumption that the code in the DVR should be able to handle the conversion, and when the law changed, they adjusted for it. As long as they have a mechanism for handling that change (and apparently they do), that's what really matters at the end of the day.

Invalid assumptions happen all the time in coding. Not to excuse them, but one example was the year 2000. No, not the Y2K bug, but a different year 2000 issue that got far less attention. When calculating for leap year, there's alot of code out there that just divides the last 2 digits by 4. If there's no remainder, then it assumes a leap year. For the most part that's correct... except for years with '00' at the end. Those years are NOT leap years. Yet there were many s/w systems that probably hiccupped that year due to that issue.


----------



## psweig (Feb 4, 2006)

jpl said:


> I don't think that's a correct analogy. GMT doesn't shift for DST. So your clock is most likely doing a conversion internally, or there's some external trigger that's telling it to shift by an additional hour. Or it could be getting a beacon, nightly, that tells it the current time. Either way, there's s/w somewhere that's making that shift for DST happen. While I would generally agree that assumptions hard-coded in systems like this are symptoms of bad coding practices, you have to draw the line somewhere. I would have said that the calculation for DST would have been a safe thing to assume in the code. In other words, for years the day and time at which the clock changes has been fixed - it's like assuming that Thanksgiving will always happen on the last Thursday of November, or election day will always be on the Tuesday following the first Monday in November. Can those change? Sure... but what's the likelihood that they will? Only Congress could be stupid enough to believe that making a change like to DST like this is a good idea.
> 
> What would have really been a bad practice, though, is if DirecTV didn't bother to adjust for it. They made a, not unreasonable, assumption that the code in the DVR should be able to handle the conversion, and when the law changed, they adjusted for it. As long as they have a mechanism for handling that change (and apparently they do), that's what really matters at the end of the day.
> 
> Invalid assumptions happen all the time in coding. Not to excuse them, but one example was the year 2000. No, not the Y2K bug, but a different year 2000 issue that got far less attention. When calculating for leap year, there's alot of code out there that just divides the last 2 digits by 4. If there's no remainder, then it assumes a leap year. For the most part that's correct... except for years with '00' at the end. Those years are NOT leap years. Yet there were many s/w systems that probably hiccupped that year due to that issue.


Yes, I remember that glitch well. Thing is, we had to write programs for this when I took my first CS class, and everybody in the class who didn't catch the "00" problem, got their programs back with orders to fix it.
It wouldn't have occurred to me that the R-15 couldn't handle it. I guess I'm just not cynical enough.


----------



## walters (Nov 18, 2005)

The way the radio-controlled clocks work is that the radio signal indicates which time is in effect (in fact, it counts down one day prior to the change). So they just moved the calculation off the end-user device and on to the server generating the radio signal. But the calculation still happens, and it's generally a text file that describes the rule (e.g. "first Sunday of April"). So that rule needs to be changed.

Don't know how the R15/HR20 work, but apparently the TiVo-based boxes have the rules (and are getting updates as we speak).


----------



## walters (Nov 18, 2005)

jpl said:


> Invalid assumptions happen all the time in coding. Not to excuse them, but one example was the year 2000. No, not the Y2K bug, but a different year 2000 issue that got far less attention. When calculating for leap year, there's alot of code out there that just divides the last 2 digits by 4. If there's no remainder, then it assumes a leap year. For the most part that's correct... except for years with '00' at the end. Those years are NOT leap years. Yet there were many s/w systems that probably hiccupped that year due to that issue.


Actually 2000 was a leap year. The rule is years divisible by 4 are, except those divisible by 100 aren't, except those divisible by 400 are. So we'll see this problem for the first time in 2100.


----------



## carl6 (Nov 16, 2005)

walters said:


> Actually 2000 was a leap year. The rule is years divisible by 4 are, except those divisible by 100 aren't, except those divisible by 400 are. So we'll see this problem for the first time in 2100.


You might see the problem in 2100. Seriously doubt I will :lol:

Carl


----------



## jpl (Jul 9, 2006)

walters said:


> Actually 2000 was a leap year. The rule is years divisible by 4 are, except those divisible by 100 aren't, except those divisible by 400 are. So we'll see this problem for the first time in 2100.


really? I stand corrected then -- my memory ain't what it used to be... that'll teach me to recall something earlier than yesterday


----------



## Crystal Pepsi Ball (Jun 29, 2004)

I just checked my R15-500 for 3/11/2007, and it shows in the guide 1:00am, 1:30am, 3:00am. So it looks like my R15 has the software on it to have the new DST rules on it.


----------



## samo (Nov 9, 2002)

walters said:


> Don't know how the R15/HR20 work, but apparently the TiVo-based boxes have the rules (and are getting updates as we speak).


Maybe your TiVo's do, but 2 of my R-10s don't. As of now, my R-15 and HR20 both show correct time change (gap in programming between 2AM and 3AM), but both R-10s show 2AM for the programming shown at 3AM on R-15.
I hope TiVo gets off their ... and fixes that in time for DST change. I guess they are too busy fixing bugs on S3 and working on a new hype (Amazon unbox) to please Wall Street suckers.


----------



## walters (Nov 18, 2005)

samo said:


> Maybe your TiVo's do, but 2 of my R-10s don't. As of now, my R-15 and HR20 both show correct time change (gap in programming between 2AM and 3AM), but both R-10s show 2AM for the programming shown at 3AM on R-15.
> I hope TiVo gets off their ... and fixes that in time for DST change. I guess they are too busy fixing bugs on S3 and working on a new hype (Amazon unbox) to please Wall Street suckers.


Your R10 needs 6.1a, which mine installed just yesterday. My guide looks fine on 3/11. Check for pending restart or make a daily call (update should already be there, but authorization to install it comes from the phone line).


----------



## Bobman (Jan 3, 2006)

This problem isnt just with the DirecTV, my BlackBerry was sent a software patch for DST recently. It was called 2007 DST patch.


----------



## samo (Nov 9, 2002)

walters said:


> Your R10 needs 6.1a, which mine installed just yesterday. My guide looks fine on 3/11. Check for pending restart or make a daily call (update should already be there, but authorization to install it comes from the phone line).


Thanks. Did daily call and restart and guide is fixed now.


----------



## ghostrider3000 (Mar 8, 2007)

So I have DirecTV Samsung Tivo unit that on my guide currently shows all next week's shows as 1 hour earlier than they are really on because DST starts 3 weeks early this year. I assume that means its probably going to tape the shows correctly but it will just list the times of the shows wrong (1 hour off) for 3 weeks. At least I hope thats the case. I dont have it hooked up to a phone line because I havent had a landline in 5 years (all cellular). 

So my question: Does anybody have any idea if the update to fix the time on my Tivo ( the update I havent received because I dont have a phone line) will fix the unit for the future twice a year DST changes that have been scheduled as well as this current 3 week one? In that case I might bother to hook it up to a phone line at a friend's house to get the update. But I'm sure not going to do that every 6 months.


----------



## Kevin Dupuy (Nov 29, 2006)

ghostrider3000 said:


> So I have DirecTV Samsung Tivo unit that on my guide currently shows all next week's shows as 1 hour earlier than they are really on because DST starts 3 weeks early this year. I assume that means its probably going to tape the shows correctly but it will just list the times of the shows wrong (1 hour off) for 3 weeks. At least I hope thats the case. I dont have it hooked up to a phone line because I havent had a landline in 5 years (all cellular).
> 
> So my question: Does anybody have any idea if the update to fix the time on my Tivo ( the update I havent received because I dont have a phone line) will fix the unit for the future twice a year DST changes that have been scheduled as well as this current 3 week one? In that case I might bother to hook it up to a phone line at a friend's house to get the update. But I'm sure not going to do that every 6 months.


I believe it will change it perminately.


----------



## TheRatPatrol (Oct 1, 2003)

So why is DST earlier this year?


----------



## rlambert7 (Feb 7, 2006)

theratpatrol said:


> So why is DST earlier this year?


The government thinks it will save us energy.


----------



## jpl (Jul 9, 2006)

rlambert7 said:


> The government thinks it will save us energy.


That's correct - this was done by Congressional action. They passed it, I think, 2 years ago to take effect in 2007. And you're right - that's the justification for it. The thinking is that it'll be lighter out when people get home from work, so that you'll use less energy as a result. It's goofy math to me. Businesses are by far the biggest consumers of electricity and if you start the work day sooner, you use more energy at the work-place while saving energy at home. And since it's (up here in the Northeast, anyway) still cold as anything out there, what this change will mean is that my company will need to run their heat more during the day in order to accomodate the employees who now have to come in earlier.


----------



## dodge boy (Mar 31, 2006)

jpl said:


> That's correct - this was done by Congressional action. They passed it, I think, 2 years ago to take effect in 2007. And you're right - that's the justification for it. The thinking is that it'll be lighter out when people get home from work, so that you'll use less energy as a result. It's goofy math to me. Businesses are by far the biggest consumers of electricity and if you start the work day sooner, you use more energy at the work-place while saving energy at home. And since it's (up here in the Northeast, anyway) still cold as anything out there, what this change will mean is that my company will need to run their heat more during the day in order to accomodate the employees who now have to come in earlier.


It was part of Bush's energy plan which of course got passed by his fellas in congress..... When they originally enacted DST they used candles to light their homes and it would get dark at 7:30 in the evenings so the idea was to save candles they could "Save daylight" until we needed it. No need to be light at 5:00 am. great idea back in the day. But to lengthen it instead of raise CAFE standards on cars, trucks and SUVs is just absurd.


----------



## rlambert7 (Feb 7, 2006)

This [earlier DST] was tried back in 1974 as an emergency measure due to the Arab oil embargo, but I think it was even a bit earlier than this one. It was TRAGIC. A few children were hit by cars, and killed because they were going to school in the dark. I hope we are far enough into the year that such tragedies will not be repeated.


----------



## wbmccarty (Apr 28, 2006)

rlambert7 said:


> A few children were hit by cars, and killed because they were going to school in the dark. I hope we are far enough into the year that such tragedies will not be repeated.


I recall these events. But, I don't get it: the idea of DST is to match daylight hours to the hours of activity. It seems that it sometimes has the opposite effect. I can't see why this should be. Does Congress have an incorrect idea as to the hours of activity? The basic idea of DST seems sound. Who's fouling it up and why?

Cheers,


----------



## jpl (Jul 9, 2006)

rlambert7 said:


> This [earlier DST] was tried back in 1974 as an emergency measure due to the Arab oil embargo, but I think it was even a bit earlier than this one. It was TRAGIC. A few children were hit by cars, and killed because they were going to school in the dark. I hope we are far enough into the year that such tragedies will not be repeated.


The one good item with the change - Halloween. DST would always end just before Halloween, since it happened on the last weekend in October, which means it would be darker when the kids went trick-or-treating, which raised the possibility that they would get hit by cars. By pushing out DST to November it helps on that end.

As for the political aspect of this, I have to agree that this is goofy - but it's bipartisan goofiness. Yeah, it was probably driven by President Bush (not exactly his finest hour), but it wasn't exactly opposed by the democrats in Congress, either. Far be it from me to withhold trouncing on one party vs. the other (hint, I'm a republican, and a strong supporter - one of the few left - of President Bush), but this really is just bipartisan nuttiness, and I'll be the first to admit that the president should have just ignored this one. Still it's one of the things that either party could/would impose. Really no different, to me, than someone telling me I should change out my lightbulbs for halogen bulbs to save the earth.


----------

