Mailing List Archive: MythTV: Dev

MythTV UTC branch merge

Index | Next | Previous | View Threaded

danielk at cuymedia

Jun 5, 2012, 10:02 AM

Post #1 of 16 (794 views)
Permalink

MythTV UTC branch merge

I've just merged the UTC branch to master. I've been running this
branch locally so I don't expect any huge problems. However this
is a fairly large change touching all parts of MythTV so I expect
there will be some problems I haven't encountered and fixed already.

This changes the internal representation of time in the database
and in the code from local time to universal coordinated time.
To the end user this means there will no longer be problems when
daylight savings time starts or ends and there won't be any problems
with connecting two machines in slightly different timezones.
i.e. "Americas/New_York" and "New York" when the machines have
two different operating systems.

For developers this means using the functions in mythdate.h
to get the current QDateTime and to format a date for output.
The QDateTime returned from Qt classes such as QFileInfo
are also in local time which means that if you plan to store
the date for future reference you should call QDateTime::toUTC()
so that it will be stored in UTC. However, if you are just
comparing it to a QDateTime in UTC Qt is smart enough to
compare them in the same timezone.

-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

john.p.harvey at btinternet

Jun 5, 2012, 11:32 AM

Post #2 of 16 (770 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

The last update for the database is failing for me
UPDATE recorded set progstart = progstart + utc_offset %1, progend = progend
+ utc_offset %2

Are those utc_offset meant to be interval?

John

-----Original Message-----
From: mythtv-dev-bounces [at] mythtv [mailto:mythtv-dev-bounces [at] mythtv]
On Behalf Of danielk
Sent: 05 June 2012 18:02
To: Development of MythTV
Subject: [mythtv] MythTV UTC branch merge

I've just merged the UTC branch to master. I've been running this branch
locally so I don't expect any huge problems. However this is a fairly large
change touching all parts of MythTV so I expect there will be some problems
I haven't encountered and fixed already.

This changes the internal representation of time in the database and in the
code from local time to universal coordinated time.
To the end user this means there will no longer be problems when daylight
savings time starts or ends and there won't be any problems with connecting
two machines in slightly different timezones.
i.e. "Americas/New_York" and "New York" when the machines have two different
operating systems.

For developers this means using the functions in mythdate.h to get the
current QDateTime and to format a date for output.
The QDateTime returned from Qt classes such as QFileInfo are also in local
time which means that if you plan to store the date for future reference you
should call QDateTime::toUTC() so that it will be stored in UTC. However, if
you are just comparing it to a QDateTime in UTC Qt is smart enough to
compare them in the same timezone.

-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

danielk at cuymedia

Jun 5, 2012, 11:46 AM

Post #3 of 16 (772 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On 06/05/2012 02:32 PM, John Harvey wrote:
> The last update for the database is failing for me
> UPDATE recorded set progstart = progstart + utc_offset %1, progend = progend
> + utc_offset %2
>
> Are those utc_offset meant to be interval?

Yes, sorry about that. I added that update later than the others
and messed it up. The safest thing to do is go back to the
db backup and then redo the update with the latest master.

-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

f-myth-users at media

Jun 5, 2012, 4:12 PM

Post #4 of 16 (763 views)
Permalink

MythTV UTC branch merge [In reply to]

Yay!

I've been wondering for a while, and figure now's the time to ask---
how does this affect the names on disk of existing recordings, which
were named using local time until now? I assume they stay constant,
and new recordings use UTC? (And what happens if someone has a
recording written using localtime, then loads this patch, and then
myth wants to create a new recording with the same name because
they're recording something from the same channel a few hours later
and the two happen to now collide? Obviously this can only happen
in a window of a few hours after starting to run this code.)

Thanks again for all this work.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

jyavenard at gmail

Jun 5, 2012, 5:02 PM

Post #5 of 16 (761 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

Does this all work with qt 4.6 yet??

Last I used some code dealing with UTC time, it was often using functions
only available from qt 4.7. The details are blurry in my memory so I was
just wondering if this merge meant a qt bump...

danielk at cuymedia

Jun 5, 2012, 5:44 PM

Post #6 of 16 (765 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On 06/05/2012 07:12 PM, f-myth-users [at] media wrote:
> Yay!
>
> I've been wondering for a while, and figure now's the time to ask---
> how does this affect the names on disk of existing recordings, which
> were named using local time until now? I assume they stay constant,
> and new recordings use UTC? (And what happens if someone has a
> recording written using localtime, then loads this patch, and then
> myth wants to create a new recording with the same name because
> they're recording something from the same channel a few hours later
> and the two happen to now collide? Obviously this can only happen
> in a window of a few hours after starting to run this code.)

Old recordings will use local time in their naming and new recordings
will use UTC. When there is a naming collision the recorder will try
again with the time incremented by one second (it increments this for
a while until it resolves the naming collision or the increment becomes
ridiculously large.)

-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

danielk at cuymedia

Jun 5, 2012, 6:11 PM

Post #7 of 16 (761 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On 06/05/2012 08:02 PM, Jean-Yves Avenard wrote:
> Does this all work with qt 4.6 yet??
>
> Last I used some code dealing with UTC time, it was often using
> functions only available from qt 4.7. The details are blurry in my
> memory so I was just wondering if this merge meant a qt bump...

No Qt bump required. The useful new functions in QDateTime are
more to do with how you initialize and use millisecond accurate
QDateTime objects. With Qt 4.6 and earlier this can be a very
tedious process. But dealing with UTC vs localtime is pretty
simple even with older Qt versions.

There are basically two methods you need to know about for
most things: QDateTime::toUTC() and QDateTime::toLocalTime()
These will convert to UTC and to local time as long as the
"timespec" property of the QDateTime is set properly. When
looking at a date coming from Qt sources the timespec will
always be set properly. When coming from the database we
can use the MythDate::as_utc() around the QDateTime for it's
timespec to be set properly; and with a UTC string
MythDate::fromString() will ensure the timespec is set.
mythdate.cpp is only 150 lines and takes care of almost all
the cases.

For converting QDateTime objects to strings MythDate::toString()
Provides all the formats we use and is smart enough to know
that if you don't specify that you want local time or UTC it
will use local time for human friendly formats and UTC for
computer friendly formats.

-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gnassas at mac

Jun 6, 2012, 11:11 AM

Post #8 of 16 (749 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On 2012-06-05, at 1:02 PM, danielk wrote:

> This changes the internal representation of time in the database
> and in the code from local time to universal coordinated time.

Just wondering if this change merits a bump to the protocol version since prior events gave recording start times in local time and now they'll be UTC.

If you have an event listener that interfaces with the services API you have (until now) had to do a local -> utc conversion on the startts. That's no longer necessary but to know that you'll have to check the db schema version which is easy enough but of course protocol version is the normal way to signal such changes.

I doubt there are that many event listener + services API clients out there but I mention this in case someone else thinks of another angle that would make a protocol bump more urgent.

- George

danielk at cuymedia

Jun 6, 2012, 11:29 AM

Post #9 of 16 (748 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On 06/06/2012 02:11 PM, George Nassas wrote:
> On 2012-06-05, at 1:02 PM, danielk wrote:
>
>> This changes the internal representation of time in the database
>> and in the code from local time to universal coordinated time.
>
> Just wondering if this change merits a bump to the protocol version
> since prior events gave recording start times in local time and now
> they'll be UTC.

The protocol version is bumped to 75 SweetRock

-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gnassas at mac

Jun 6, 2012, 11:35 AM

Post #10 of 16 (747 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On 2012-06-06, at 2:29 PM, danielk wrote:

> The protocol version is bumped to 75 SweetRock

Ahh, OK. The week difference in commits caught me.

- George

andrew at etc

Jun 8, 2012, 3:18 AM

Post #11 of 16 (731 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On Wed, 2012-06-06 at 14:29 -0400, danielk wrote:
> On 06/06/2012 02:11 PM, George Nassas wrote:
> > On 2012-06-05, at 1:02 PM, danielk wrote:
> >
> >> This changes the internal representation of time in the database
> >> and in the code from local time to universal coordinated time.
> >
> > Just wondering if this change merits a bump to the protocol version
> > since prior events gave recording start times in local time and now
> > they'll be UTC.
>
> The protocol version is bumped to 75 SweetRock

Would someone please send me an XML dump for the backend status so I can
update mythtv-status for this change?

Cheers!

--
Andrew Ruthven
Wellington, New Zealand
At home: andrew [at] etc | linux.conf.au 2013
| Come join the party...
| http://linux.conf.au

Attachments:

signature.asc (0.19 KB)

gnassas at mac

Jun 8, 2012, 6:55 AM

Post #12 of 16 (724 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On 2012-06-05, at 1:02 PM, danielk wrote:

> I expect
> there will be some problems I haven't encountered and fixed already

Hi, something I just noticed is in the update message for the recording list change backend message the four times are still local even though the db versions are UTC.

I'm running master from Wednesday afternoon (v0.26-pre-519-g48c9f6e) just after the recordseek fix went in. Oh, and I do have the timezone tables present in MySQL.

I can open a ticket with a patch if you like but I assume it's trivial and you'd like to fix it as part of the rest of the UTC changes.

- George

gnassas at mac

Jun 8, 2012, 9:41 AM

Post #13 of 16 (722 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On 2012-06-08, at 9:55 AM, George Nassas wrote:

> the update message for the recording list change backend message the four times are still local even though the db versions are UTC.

Found a sec to look closer. The problem is the DATETIME_TO_LIST macro in libs/libmyth/programinfo.cpp which writes using toTime_t(). There's also a similar macro in libs/libmythbase/filesysteminfo.cpp but it doesn't appear to be invoked.

This might be a good time to switch the five fields (startts, endts, recstartts, recendts, and lastmodified) to UTC strings instead of local numbers. I can submit a patch if the powers that be agree.

- George

danielk at cuymedia

Jun 8, 2012, 6:51 PM

Post #14 of 16 (709 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On 06/08/2012 12:41 PM, George Nassas wrote:
> On 2012-06-08, at 9:55 AM, George Nassas wrote:
>
>> the update message for the recording list change backend message the
>> four times are still local even though the db versions are UTC.
>
> Found a sec to look closer. The problem is the DATETIME_TO_LIST macro in
> libs/libmyth/programinfo.cpp which writes using toTime_t(). There's also
> a similar macro in libs/libmythbase/filesysteminfo.cpp but it doesn't
> appear to be invoked.
>
> This might be a good time to switch the five fields (startts, endts,
> recstartts, recendts, and lastmodified) to UTC strings instead of local
> numbers. I can submit a patch if the powers that be agree.

toTime_t() & fromTime_t() should work just fine. time_t is always in
UTC so this would be unchanged across the wire from pre-utc merge.

Anyway, I don't know what you mean by this "the update message for
the recording list change backend message the four times are still
local even though the db versions are UTC."

Can you give the MythProto command name or just the screen you are
seeing an issue with?

-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gnassas at mac

Jun 8, 2012, 10:16 PM

Post #15 of 16 (710 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On 2012-06-08, at 9:51 PM, danielk wrote:

> Can you give the MythProto command name or just the screen you are
> seeing an issue with?

I'm talking about this message:

http://www.mythtv.org/wiki/RECORDING_LIST_CHANGE_(Myth_Protocol)#UPDATE

who's ProgramInfo portion comes from the source I mentioned.

But, what you said about time_t makes me think some more and it seems the problem is on my side.

I have a custom event listener which also interfaces with the services API. Before the UTC merge I had to do various local/UTC conversions which are now unnecessary. While removing those I created one around the time_t values which looked like a myth bug. I even checked twice before posting. Oh well.

Sorry for the noise!

- George

gnassas at mac

Jun 9, 2012, 5:56 PM

Post #16 of 16 (687 views)
Permalink

Re: MythTV UTC branch merge [In reply to]

On 2012-06-05, at 1:02 PM, danielk wrote:

> I don't expect any huge problems. However this
> is a fairly large change touching all parts of MythTV so I expect
> there will be some problems I haven't encountered and fixed already

Just noticed this - in the "Upcoming Recordings" display on the frontend the yesterday/today/tomorrow shortform bit seems to be based on the UTC time. As I write it's Saturday night here but Sunday in UTC land yet the recording I have coming up in an hour says it's scheduled for yesterday and Monday's recordings say tomorrow.

- George

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads