Opened 15 years ago
Closed 15 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 |
Description
This should be valid but isn't:
2009-08-13 08:23:41.940 Connecting to backend server: 10.0.0.4:6543 (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 15 years ago by
comment:2 Changed 15 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
#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.
Do #5872 or #5896 Help?