[mythtv-users] duplicate recordings

[Michael T. Dean]

On 10/10/2011 11:52 AM, John Pilkington wrote:
> On 09/10/11 19:23, Michael T. Dean wrote:
>> On 10/09/2011 01:42 PM, Mike Perkins wrote:
>>> On 09/10/11 18:20, Dan Armbrust wrote:
>>>> Of course, then again, I'm complaining about the scheduler that can't
>>>> figure out that DST happens twice a year, and completely hoses itself
>>>> every time that switch happens.  Guess I shouldn't expect much here
>>>> either.
>>> For you, maybe. I should imagine the majority of users like myself have no
>>> problems at all.
>> Exactly, Mike.  It always does exactly what the rules tell it to do.
>> However, it just doesn't account for the fact that the system time will
>> change in the middle of the recording.  So, you just have to take that
>> into account if you're recording a program that starts at/crosses/ends
>> at the local boundary.
>>
>> Don't worry, though--it will eventually be changed to store all data in
>> UTC-a /large/ effort with almost no benefit that is sure to cause bugs
>> for months after the change (likely even for users who only run stable
>> MythTV).  Then, we won't have to listen to people complain (without
>> submitting patches, no less) about how "MythTV should use UTC."  Also,
>> it will mean that those of you who directly access data in the database
>> will be nice and confused.  :)
>>
>> Note, also, that MythTV was /explicitly/ designed to use local time in
>> the database.  This is not an oversight.  This is not a bug.  This was a
>> design decision that was made specifically because it had many benefits
>> and the only disadvantage happened during a time period of a maximum of
>> 2 hours per year--that's 1/4380th of the year where a user has to think
>> (and only those users in areas with DST and only those users who
>> actually record something that airs at the time of the DST switch).
>>
>> Of course, my statement that it will change to UTC presupposes that
>> we'll actually have a time zone database in the future--since there
>> currently exists none for *nix systems.
> I wondered what Mike was referring to here.  Then I found out.
>
> http://en.wikipedia.org/wiki/Tz_database#2011_lawsuit
>
> http://www.zdnet.co.uk/news/compliance/2011/10/07/internet-time-guide-scotched-by-astrology-firm-40094137/
>
> Usually, of course, it's easy to find the offset of local time from UTC;
>    it's compiling a global database that's fraught.

The point is that MythTV doesn't need to know the offset of local time 
from UTC /right now/.  MythTV needs to know the offset of local time 
from UTC at all points from the first recording until you stop using 
MythTV.  /That/ is what's challenging to compile.  MythTV's use of time 
zone is /not/ a simple "how much offset is there from UTC right now?"

> Really another argument for moving to UTC as the reference for myth.

Actually, doesn't really change anything.  If you have a database that 
allows determination of the offset at any given point in time through 
history/future, you can use UTC for storage and convert to local time 
for display/UI.  If you lack that database, the best you can do is 
either not do conversions (so switching to UTC would mean all times are 
stored /and/ displayed in UTC) or assume some offsets when you display 
times--which may or may not be accurate, as politicians love to change 
the when of the DST switch (ref 2007 in the US--and I'm sure I'm not the 
only MythTV user who started using MythTV before 2007, so there will be 
real users affected by simplistic, database-less).

That said, the database is basically back, as of today ( 
http://mm.icann.org/pipermail/tz/2011-October/008016.html ), but we'll 
see what happens on the legal front.  I really hope the Astrolabe case 
goes to court and all their claims are nullified (as Olsen DB uses only 
facts from the atlas by ACS (that Astrolabe just purchased) and isn't 
even using the representation/specific compilation from the atlas).

BTW, this database is the one used by all *nix systems, Java, PHP, 
MySQL, Android, Mac OS X, and a /lot/ of other software that's used 
around the world.  Basically, every software package in the world that 
uses time zone information--with the one glaring exception being MS Windows.

Mike