[mythtv] [mythtv-commits] mythtv branch master updated by gigem. v0.26-pre-525-g7fb9747

R. G. Newbury newbury at mandamus.org
Tue Jun 12 21:16:57 UTC 2012


On 06/12/2012 11:13 AM, Michael T. Dean wrote:
> On 06/12/2012 10:54 AM, Jean-Yves Avenard wrote:
>> On Tuesday, 12 June 2012, Michael T. Dean wrote:
>>> Yeah, good point. It's now looking like some of the final conversion
>>> stuff for the recording rules that David E is working on will require
>>> a DB
>>> update that requires time-zone data inside the database, so at that
>>> point,
>>> we'll have to put in the check on DB upgrade.
>> IMHO, having to set a new local time zone setting in the database,
>> completely defeat the purpose of doing everything in UTC...
>> All you've done is shift the problem elsewhere...
>>
>> If moving to UTC internally, means you have to fail if a time zone isn't
>> set, why bother with UTC in the first place?
>
> You don't have to actually set the time zone in MySQL--MySQL will pick
> that up from the local system's time zone setting. You just have to load
> the time zone rules from the Olsen database in /usr/share/zoneinfo into
> tables in MySQL so that MySQL can do conversions across time zones. Running
>
> mysql_tzinfo_to_sql /usr/share/zoneinfo > /tmp/tzinfo.sql
>
> will allow you to see exactly what it's doing.
>
> This is something that doesn't require any specific configuration, and
> probably should be done as part of a normal MySQL package install, but
> it seems that either there aren't many other applications that require
> the data in MySQL or each application's package handles the loading
> itself. I have no idea why the MySQL developers decided not to load the
> data automatically when you run mysql_install_db or something (at least
> on *nix systems with zoneinfo DB on them).


Then loading the zoneinfo tables needs to be done in the mysql setup ( 
or in mc.sql for trunk installs), Problem is that the 'usual' route of 
"mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -ppassword 
mysql"  requires entry of the mysql root password.

So it cannot be done in mysql_prepare_db as ExecStartPre in mysql.service.

This *is* messy. And there seems to be no way around it.

Geoff





More information about the mythtv-dev mailing list