[mythtv-commits] Ticket #5319: Add QUERY_TIMEZONE to Myth Protocol

Sun May 11 01:36:22 UTC 2008

#5319: Add QUERY_TIMEZONE to Myth Protocol
----------------------------------------------+-----------------------------
 Reporter:  sphery <mtdean at thirdcontact.com>  |        Owner:  ijr    
     Type:  patch                             |       Status:  new    
 Priority:  minor                             |    Milestone:  unknown
Component:  mythtv                            |      Version:  head   
 Severity:  medium                            |   Resolution:         
  Mlocked:  0                                 |  
----------------------------------------------+-----------------------------

Comment(by sphery <mtdean at thirdcontact.com>):

 After posting the initial version of the patch, David Shay, Rob Smith, and
 I began discussing the patch to determine if there was a simpler (or more
 platform-independent) way of accomplishing the desired result.  After much
 discussion we realized that as long as dates are stored in the database in
 local time and manipulated on other hosts (where date manipulation
 functions in Qt or PHP or whatever will use the local rules defined for
 the time zone), in fact, the initial implementation was too naive.  Rather
 than simply identifying the currently-in-effect time zone name (i.e.
 Eastern Standard Time (EST) or whatever), detecting time zone
 misconfiguration requires identifying the currently configured rules for
 application of the time zone (i.e. "America/New_York")--what I'll call the
 time zone ID.

 The patch mythtv-5319-add_query_timezone_to_protocol-20080510.patch
 (replaces mythtv-5319-add_query_timezone_to_protocol.patch ) provides a
 much more robust algorithm that attempts to identify the time zone ID.
 AIUI, there are generally only 2 time zone databases in use on computer
 systems today--the zoneinfo database and the Windows time zone database
 (though some systems have no time zone database and, instead, use POSIX
 specifiers).  Using the zoneinfo database identifiers makes more sense for
 MythTV as zoneinfo is used by glibc (and, therefore, by GNU/Linux systems)
 as well as many different programming languages (PHP, Java, ...), so the
 only mapping from one database to another will have to be done on the
 Windows platform.

 Unfortunately, though, there are no functions provided by glibc, Qt (or
 anything else I could find) to determine which specific rules are
 configured for use on a system.  Though POSIX provides functionality for
 determining the currently-in-effect time zone name and/or offset, it
 provides no functionality for determining the rules for the application of
 the time zone.  Therefore, to identify the currently-configured time zone
 ID requires "parsing" the system configuration.

 The algorithm I used was adapted from that used by the (GPL2-licensed)
 OpenJDK software (in C).  I converted the algorithm to take advantage of
 Qt and modified the (Red-Hat-centric) approach used so that it also
 supports Debian-based systems' configuration mechanism.  Like the OpenJDK
 code, the patch provides a fallback approach that should always work even
 if we can't parse a configuration file (i.e. for systems which use neither
 the Red-Hat /etc/sysconfig/clock "ZONE=" nor the Debian /etc/timezone
 approach--my system is one of these and it works great for me).  Since the
 algorithm is no longer trivial and will be needed on frontend and backend
 systems, I moved it into libmyth (util.{h,cpp}) in the form of one MPUBLIC
 function and two static helper functions.

 I also changed the command to return "<time zone ID>[]:[]<UTC
 offset>[]:[]<current time>" (i.e.
 "America/New_York[]:[]-04:00[]:[]2008-05-10T20:46:34") to make it easier
 for the client to determine whether configured time zones /and/ currently-
 set time match, or--in the event that some information could not be
 determined--that configuration "seems close enough for now."

 Also, in researching, I found out that "time zone" is, in fact, properly 2
 words, so I modified the protocol command to be QUERY_TIME_ZONE.  The new
 myth_time_zone.pl test script (replacing myth_timezone.pl ) takes this
 into account and also handles the additional data.

 The patch does not attempt to cache the information it finds.  If
 QUERY_TIME_ZONE is used often enough to warrant caching the result, we
 must ensure we only cache time zone ID's and not time zone names (EST or
 whatever) as the time zone name will change after the start/end of DST.
 Generally, I see this command being used only on startup of slave backends
 or frontend clients.  For "stateless" clients, like MythWeb, the client
 should choose an appropriate interval to query the time zone.  Therefore,
 I didn't think it would be called often enough to warrant caching in the
 MythContext.  Regardless (and regardless of the seeming inefficiency of
 the approach we have to use), determining the currently-configured time
 zone ID is fast (in testing the compare-/etc/localtime-to-files-
 in-/usr/share/zoneinfo approach, my Athlon XP 1700+ test system took less
 than 0.3 seconds real time and less than 0.05 seconds CPU time even when
 configured with the "last" file, to make it look through every file in
 /usr/share/zoneinfo--and this was running it as a separate QApplication-
 based test binary, so that time included process and environment set up).

 This patch does not provide any Windows functionality for detecting the
 time zone ID (even the localtime_r() functionality is #ifndef'ed for
 Windows as localtime_r() doesn't exist on mingw).  In order for Windows
 hosts to take advantage of the (future) functionality which requires
 QUERY_TIME_ZONE (i.e. identifying misconfigured time zones or allowing
 MythWeb to adjust when its host's time zone is different from that
 specified on the master backend), Windows-specific functionality will be
 required.  The OpenJDK files jdk/src/share/native/java/util/TimeZone.c (
 getPlatformTimeZoneID() ) and
 jdk/src/windows/native/java/util/TimeZone_md.c ( findJavaTZ_md() and
 getWinTimeZone() ) provide a good example approach.  Basically, though,
 the Windows API's are used to determine the Windows time zone settings and
 then the Windows rules must be mapped to the appropriate zoneinfo database
 ID.

 Currently on Windows, the time zone ID will be "UNDEF" and only the UTC
 offset and current time will be provided.

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/5319#comment:1>
MythTV <http://www.mythtv.org/>
MythTV