I don't understand! If timers are stored in local time, and as a user I want to record a show that is due to start at say 1:00pm Tuesday 1/11, ie. my local time of 1:00pm, what has DST got to do with it? If the desired local time is stored then as long as the PVR has the correct time, the timer will fire correctly, right?
Hi John,
I don't pretend to speak for IceTV, but I'll try and give some examples that might explain why, if I were in their position, I'd make the same decision and do everything in UTC.
Thought experiment #1: Imagine that I'm a fan of the 4 am American evangelical TV shows and record them all to watch at a more reasonable time. I'm not prepared to get up and change the local time on the PVR at 3 am, after DST has started. I am also not prepared to set the clock forward when I go to bed, because I am also a SF fan and need to record whatever incarnation of Star Trek is on "After Nightline". (If this seems too far-fetched, then imagine that I am away for a week around DST changeover day.) Unless my PVR knows to swap over automatically, then one of those recordings is going to be wrong.
Rule #1 of Time Zones: No matter what, the PVR has to know the daylight saving rules.
Religiously adhering to storing timers in local time, and having the PVR know only about local time, just isn't going to help here.
The sad fact is that most PVRs, in the long term, fail to satisfy Rule #1 of Time Zones. Only a heavyweight solution like Tony's timezone code in EPG_Uploader (which is essentially the same as what all Unix systems do) is likely to be future-proof enough to withstand the harebrained whims of our dear governments.
Thought experiment #2: Imagine that I live near a timezone boundary. It might only be a timezone boundary for part of the year. There isn't really a place in Australia that demonstrates this well. Perhaps the best is the NSW/Queensland border around Tweed Heads, or the extreme SE of South Australia around Mt Gambier or Naracoorte. I receive TV broadcasts from both sides of the boundary. For some of those broadcasts, my local time is the same as the broadcaster's. For others, my local time differs (either because I am observing different DST to the broadcaster, or because I am across a permanent timezone boundary). The guide data I get from these other broadcasts is going to be wrong *for me*, but it's right for the broadcaster.
Rule #2 of Time Zones: "Half an hour earlier in Adelaide" does not mean I can cheat the lottery by watching Adelaide broadcasts.
So if I get my guide from the broadcaster in the broadcaster's local time I have to know the DST and timezone rules for every broadcaster that I receive (which, for satellite TV, could easily be the other side of the world). In the general case, converting a local time from one timezone to the other is best done by converting the first timezone to UTC, and then converting UTC to the other time zone. Because of Rule #2, UTC is, in the general case, unavoidable.
For many people, me included, Rule #2 is hard to notice. Anyone in the Eastern Standard Chauvinist Time zone in Australia barely thinks about it unless they are watching the Second Test at the WACA.
With so many variables, some of the time zone processing decisions really have to be delegated down the line, not done by the EPG provider but by the PVR, which knows where it is, and so ought to know its own time zone. There are parallels here with other discussions I've seen about what IceTV does or doesn't do: Why doesn't IceTV Interactive merge adjacent timers on the same channel? Why doesn't IceTV Interactive alert you when you have too many timers and not enough tuners? Why doesn't IceTV interactive handle before-and-after padding? The answer's the same: those are things that IceTV has decided are the responsibility of the PVR (or its operator).
Anything that IceTV adds to the guide data to try to cope with all of these variables is like adding epicycles to the heliocentric model of the solar system: eventually the system gets so convoluted that it's unavoidable to change your point of reference. None of these problems comes up if the guide data is maintained and disseminated in UTC.
One thing I agree with you on is that the end user shouldn't really be having to think about time zones, that it should Just Work. Unfortunately, PVR manufacturers are often still of the opinion that it's OK for users to be manually setting the clock forward or back an hour, as if the PVR were a microwave oven. PVR manufacturers, please pay attention: It's Not OK. You cannot cut corners with DST, and you cannot assume that this year's rule is going to occur in perpetuity. Please Do It Right.
(I should mention that I once wrote a timezone library for a MUD, and I tried to cut corners, which is why I learned the lessons that I am trying to teach here. That's why I feel qualified to speak about this issue.)