| Summary: | Evolution does not adopt system-set time zone | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Alex Ladd <aladd> | ||||
| Component: | evolution-data-server | Assignee: | Milan Crha <mcrha> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.8 | CC: | cww, jwright, mcrha, mkolbas, mpoole | ||||
| Target Milestone: | rc | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-08-15 20:13:48 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | 956284 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Alex Ladd
2016-11-04 15:53:54 UTC
Thanks for a bug report. What is your exact timezone set in the system please? Also, what does this return: $ ls -l /etc/localtime if it's not a link to a file under /usr/share/zoneinfo/, could you upload it here, please? $ date Wed Nov 9 16:06:04 EST 2016 $ ls -l /etc/localtime -rw-r--r--. 1 root root 3519 May 4 2010 /etc/localtime Created attachment 1220504 [details]
localtime file from affected system
Thanks for the update. That it's the real file is the main issue. The evolution tries several ways to detect the system time zone [1], but real file comparison is used as the last option, due to performance hits. The timezone was detected from /etc/sysconfig/clock for me, when I used your localtime file. The easiest is to make the /etc/localtime a symbolic link to the correct timezone, like here: # rm /etc/localtime # ln -s /usr/share/zoneinfo/America/New_York /etc/localtime I do not think there is anything else to be done here, in the evolution-data-server, because using the exact file compare just means a significant performance hit. The question is how it happened that your /etc/localtime is a real file, not a symbolic link, but that's also out of the evolution-data-server hands. [1] https://git.gnome.org/browse/evolution-data-server/tree/calendar/libecal/e-cal-system-timezone.c?h=gnome-2-32#n425 Here [1] is a test program which has extracted the timezone detection code from the evolution-data-server and has added more debug prints for the matter of detection what it tried and what failed or worked. The convention of soft links were in the code since the very beginning. I do not know why it is wrong for the RHEL 6 though, I'm sorry. [1] https://bugzilla.gnome.org/show_bug.cgi?id=774304#c5 If I read it properly, then the problem isn't specifically "/etc/localtime being a symlink", but that an update of the tzdata package rewrites this symlink with a real file depending on the content of /etc/sysconfig/clock in RHEL 6 (though tzdata-2016j-1 seems to not do that), and that the /usr can be a separate partition in RHEL 6, mounted later than /, thus having the symlink pointing to an unexisting files early during the boot. The reliable way of obtaining the correct timezone in RHEL 6 then seems to be /etc/sysconfig/clock, despite its comment at the top. There is bug #956284 with some fixes about underscores and spaces in the ZONE key. The evolution-data-server 2.32.3-25 uses these methods, in this order, to determine the current timezone (it uses more, but these are the first related): /* cheap and "more correct" than data from a config file */ system_timezone_read_etc_localtime_softlink, /* reading various config files */ system_timezone_read_etc_timezone, system_timezone_read_etc_sysconfig_clock, system_timezone_read_etc_sysconfig_clock_alt, system_timezone_read_etc_TIMEZONE, From which I believe the fix for bug #956284 will correct this too, especially if the update of the system-config-date will also update the /etc/sysconfig/clock, without the need to make any changes by a user. |