Add QUERY_TIMEZONE to Myth Protocol

[sphery <mtdean@…>]

The attached patch adds a new protocol command, QUERY_TIMEZONE, which returns the timezone offset and name for the backend (eg -0400[]:[]EDT). It's meant to be used to fix issues such as #4683 or to allow, for example, identifying when remote systems are set to use different timezones from the master backend so we can error out on startup with a message rather than allowing startup and having playback/recording issues.

The code uses localtime_r() since I couldn't find any Qt-provided approach for determining the local timezone. Also, localtime_r() doesn't exist on mingw, so the code is disabled for the Windows port (which will return UNDEF[]:[]UNDEF for now). Please let me know if there's a better or more portable approach I should take.

The "-protocol_version_change" patches simply update the protocol version in mythcontext.h, the Perl and Python bindings, and MythWeb. I also included a simple Perl script which uses the bindings to test the new command.

[sphery <mtdean@…>]

main patch

[sphery <mtdean@…>]

protocol version change for everything except MythWeb

[sphery <mtdean@…>]

protocol version change for MythWeb

[sphery <mtdean@…>]

Perl-bindings-based test script

[sphery <mtdean@…>]

Replaces mythtv-5319-add_query_timezone_to_protocol.patch

[sphery <mtdean@…>]

Replaces myth_timezone.pl

[sphery <mtdean@…>]

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.

[sphery <mtdean@…>]

Added mythtv-5319-use_toUTC_for_calc_utc_offset.patch , which is a trivial patch that uses the new-in-Qt4 QDateTime::toUTC() function in calc_utc_offset() to get a new QDateTime with the same time as loc, but expressed as UTC rather than creating two different QDateTime objects at slightly different times. It also modifies the QDateTime::currentDateTime() call to use the Qt4, no-argument function rather than the Qt3-support function that takes a timespec.

[sphery <mtdean@…>]

Uploaded wrong version first time. Replaces mythtv-5319-use_toUTC_for_calc_utc_offset.patch

[sphery <mtdean@…>]

Patch that updates the protocol version in the doxygen example

[sphery <mtdean@…>]

Updated patch, now that MYTH_PROTO_VERSION is defined in mythversion.h

[sphery <mtdean@…>]

mythtv-5319-add_query_timezone_to_protocol-protocol_version_change-20080703.patch updates mythtv-5319-add_query_timezone_to_protocol-protocol_version_change.patch for recent library reorganization, specifically the moving of MYTH_PROTO_VERSION to mythversion.h .

Quick overview for committer:

Current patches that should be applied:

mythtv-5319-add_query_timezone_to_protocol-20080510.patch mythtv-5319-add_query_timezone_to_protocol-protocol_version_change-20080703.patch mythtv-5319-protocol_version_change_doxygen.patch mythweb-5319-add_query_timezone_to_protocol-protocol_version_change.patch mythtv-5319-use_toUTC_for_calc_utc_offset-version2.patch

myth_time_zone.pl is a simple script that allows you to test the new QUERY_TIME_ZONE command, but should not be committed.

[sphery <mtdean@…>]

Updated patch for recent changes to trunk

[sphery <mtdean@…>]

Updated patch for recent changes to trunk.

[sphery <mtdean@…>]

Added mythtv-5319-require_same_time_zone_settings_on_sbe_and_frontends.patch , which checks the local time zone settings against those on the master backend and prevents frontend or slave backend startup if settings or current time disagree. In the event that setting(s) cannot be determined, the patch warns the user that things may break, but allows startup.

Current patches:

• mythtv-5319-add_query_timezone_to_protocol-20080729.patch
• mythtv-5319-add_query_timezone_to_protocol-protocol_version_change-20080703.patch
• mythtv-5319-protocol_version_change_doxygen.patch
• mythweb-5319-add_query_timezone_to_protocol-protocol_version_change.patch
• mythtv-5319-use_toUTC_for_calc_utc_offset-20080729.patch
• mythtv-5319-require_same_time_zone_settings_on_sbe_and_frontends.patch

[sphery <mtdean@…>]

Updated patch for recent include changes in util.cpp

[sphery <mtdean@…>]

Updated for recent protocol version change

[sphery <mtdean@…>]

Updated for recent protocol version change

[sphery <mtdean@…>]

Updated for recent protocol version change

[sphery <mtdean@…>]

mythtv-5319-use_toUTC_for_calc_utc_offset-20080729.patch is obsoleted by [18572] which made a close-enough to the same change. Therefore (and with the other updated patches), the current set of patches to use is:

• mythtv-5319-add_query_timezone_to_protocol-20080927.patch
• mythtv-5319-add_query_timezone_to_protocol-protocol_version_change-20081006.patch
• mythtv-5319-protocol_version_change_doxygen-20081006.patch
• mythweb-5319-add_query_timezone_to_protocol-protocol_version_change-20081006.patch
• mythtv-5319-require_same_time_zone_settings_on_sbe_and_frontends.patch

[Janne Grunau]

(In [18574]) Adds QUERY_TIMEZONE to mythtv protocol

let frontend or remote backend start fail if any discrepancies are detected Fixes #5319 by applying patch from sphery <mtdean [aT} thirdcontact {dOt] com>

[Janne Grunau]

(In [18580]) Mythweb protocol update accidentally omitted in [18574]

Refs #5319

[Janne Grunau]

(In [18587]) allow spaces in time zone IDs

Fixes #5991, Refs #5319 From sphery <mtdean thirdcontact com>

[Janne Grunau]

(In [18588]) Printf format specifier do not work with QString. Refs #5319

[Janne Grunau]

(In [18611]) move the time zone check in mythfrontend after MythMainWindows? is created

fixes a segfault for reporting a protocol version mismatch. Refs #5319

[Janne Grunau]

(In [18619]) Add RegExp? based parsing of Debian's /et/timezone to avoid false positives

consolidtes the allmost equal parsing of /etc/timezone and /etc/sysconfig/clock into a helper function Refs #5319

[Janne Grunau]

(In [18621]) Allow '+' in the time zone ID. Refs #5319

[Anduin Withers]

(In [18792]) Closes #5268, #5319

• Allows for checkTimeZone() to not establish a connection to the MBE.
• Changes the way checkTimeZone() works for SBEs
  • Create a dummy Monitor connection to the MBE which doesn't accept events and is closed after checkTimeZone() is done.
  • Only perform checkTimeZone() if the MBE is running, previously it enforced a startup order we've never done before.
• Some minor cleanup I've had sitting around.

What I didn't do, make the tz checking happen on each SBE reconnect, doing so would now be easy but seems a little overboard.

Note: This doesn't fix the issue originally reported in #5268. I haven't found the other cause but it is likely the same issue (some function in MythContext being called that establishes an event connection to the MBE).