Opened 11 years ago

Closed 11 years ago

#6838 closed defect (invalid)

OSX Frontend uses different timezone database then linux backend

Reported by: Rob Smith Owned by: sphery
Priority: minor Milestone: unknown
Component: Ports - OSX Version: head
Severity: medium Keywords: OSX, Timezone
Cc: Ticket locked: no


This should be valid but isn't:

2009-08-13 08:23:41.940 Connecting to backend server: (try 1 of 5)
2009-08-13 08:23:41.941 Using protocol version 46
2009-08-13 08:23:41.998 Time zone settings on the master backend differ from those on this system.
2009-08-13 08:23:41.998 Detected time zone settings:
    Master: Zone ID: 'PST8PDT', UTC Offset: '-25200', Current Time: '2009-08-13T08:23:41'
     Local: Zone ID: 'US/Pacific', UTC Offset: '-25200', Current Time: '2009-08-13T08:23:41'

2009-08-13 08:23:41.998 The time and/or time zone settings on this system do not match those in use on the master backend. Please ensure all frontend and backend systems are configured to use the same time zone and have the current time properly set.
2009-08-13 08:23:41.998 Unable to run with invalid time settings. Exiting.

Change History (2)

comment:1 Changed 11 years ago by robertm

Do #5872 or #5896 Help?

comment:2 Changed 11 years ago by sphery

Resolution: invalid
Status: newclosed

#5872 (which I'll be applying in a couple of days) would allow you to use differently-named, but identical time zones on different hosts. However, PST8PDT and US/Pacific are actually different time zones--in spite of the fact that the current time in both zones is identical, they have differed in the past.

AIUI, PST8PDT is a simplified (and non-existent or "virtual") zone that will always pretend that Daylight Saving Time (DST) changes have always occurred in the past according to whatever happens to be the current rules in place for the US/Pacific (and, also, America/Los_Angeles) time zone. On the other hand, the US/Pacific (and America/Los_Angeles) time zone actually identifies exactly when DST changes really occurred each year since 1970.

Therefore, any recordings (and their program information) made during the times when the zones disagree on the application of DST could not be shared by MythTV processes running with those differing zones. And, since the start and end of DST in the US was changed in 2007, these particular zones could cause problems for recordings made as recently as 2006.

You can check whether time zones are identical by comparing their zoneinfo files:

$ sha1sum /usr/share/zoneinfo/{PST8PDT,US/Pacific,America/Los_Angeles}
e8f5742d0106cfe37cdc7077f06e6096674ec968 /usr/share/zoneinfo/PST8PDT
672f38f4c16cb8d49777de607deaf270d73ade0c /usr/share/zoneinfo/US/Pacific
672f38f4c16cb8d49777de607deaf270d73ade0c /usr/share/zoneinfo/America/Los_Angeles

If time zones actually differ (as, above, US/Pacific and America/Los_Angeles are identical but differ from PST8PDT), you will need to ensure that all MythTV processes (frontends/backends/mythtranscode/...) execute with the exact same time zone specified as the one used by your master backend. You may change the time zone used by a process with:

export TZ='US/Pacific'

before executing the application. However, since you must do this in each environment in which any MythTV application on the host will execute, it's generally easiest to simply change the system time zone on all hosts running MythTV applications to be identical.

Note: See TracTickets for help on using tickets.