RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1236667 - RHEL 6 does not provide a canonical way of obtaining the timezone (/etc/timezone)
Summary: RHEL 6 does not provide a canonical way of obtaining the timezone (/etc/timez...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: system-config-date
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jan Synacek
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-29 16:51 UTC by Andrew John Hughes
Modified: 2016-09-15 09:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-15 09:10:19 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Andrew John Hughes 2015-06-29 16:51:58 UTC 
OpenJDK needs to obtain the currently selected timezone in order to provide an appropriate default timezone from Java.

It tries a number of methods to obtain this, but, as can be seen from bug 489586 and bug 995488, none of them are ideal:

1. /etc/sysconfig/clock is checked, but this runs into issues where the zone ID is changed to include spaces (e.g. "America/New York" instead of "America/New_York"). Support was removed in bug 489586, but then had to be reinstated in bug 995488 as there was no way to differentiate between zones with the same data but a different ID. We're now hitting 489586 again; see bug 1236619.

2. If /etc/localtime is a symlink, this is followed to find the actual timezone file and thus its name. This seems to be the case on RHEL 7, but not 6.

3. /etc/localtime is compared to the files in /usr/share/zoneinfo, but there can be multiple matches (bug 995488).

In discussing bug 995488, we were told that both #1 and #2 are unsupported and /etc/sysconfig/clock had no guaranteed format, being for the use of system-config-date only. It was proposed then that /etc/timezone was introduced, which is the method used on Debian-based systems and is supported upstream by OpenJDK (and thus by the proprietary Oracle JDKs too). However, nothing was done to make this happen and the hack for /etc/sysconfig/clock was simply added back into OpenJDK, regressing bug 489586.

So I'm again proposing that /etc/timezone is provided on RHEL. It's a simple text file containing the zone name as it exists in /usr/share/zoneinfo e.g.

$ cat /etc/timezone 
America/New_York

It's simpler to parse than /etc/sysconfig/clock and not subject to the varying versions that are floating around.

Alternatively, I'm open to other suggestions, but they are likely to require work to get the changes into upstream OpenJDK and thus may never be supported on some older versions.
Comment 3 Andrew John Hughes 2015-08-26 16:09:32 UTC 
Any news on this?
Comment 11 Jan Synacek 2016-09-15 09:10:19 UTC 
(In reply to Andrew John Hughes from comment #0)
> OpenJDK needs to obtain the currently selected timezone in order to provide
> an appropriate default timezone from Java.

I wonder... How do other applications on RHEL6 do it? Isn't there a way to parse the raw /etc/localtime?

> 1. /etc/sysconfig/clock is checked, but this runs into issues where the zone
> ID is changed to include spaces (e.g. "America/New York" instead of
> "America/New_York"). Support was removed in bug 489586, but then had to be
> reinstated in bug 995488 as there was no way to differentiate between zones
> with the same data but a different ID. We're now hitting 489586 again; see
> bug 1236619.

This will be fixed, see https://bugzilla.redhat.com/show_bug.cgi?id=956284.

> 2. If /etc/localtime is a symlink, this is followed to find the actual
> timezone file and thus its name. This seems to be the case on RHEL 7, but
> not 6.

Yes, that's a problem and I guess it should be a symlink. I'd rather not change it, though, as it would potentially be a big change and it's quite late for that in RHEL6.

> So I'm again proposing that /etc/timezone is provided on RHEL. It's a simple
> text file containing the zone name as it exists in /usr/share/zoneinfo e.g.

This would not improve anything if there's basically the same information as in /etc/sysconfig/clock. Also, /etc/timezone is *not* present/supported on RHEL7, therefore, I don't want to introduce it, as it would automatically mean a regression there.

> It's simpler to parse than /etc/sysconfig/clock and not subject to the
> varying versions that are floating around.

What versions? Floating where? I thought there was only one version on RHEL6.

> Alternatively, I'm open to other suggestions, but they are likely to require
> work to get the changes into upstream OpenJDK and thus may never be
> supported on some older versions.

Since there are already workarounds present in OpenJDK that are basically RHEL6 only, I'm closing this bug.
Note You need to log in before you can comment on or make changes to this bug.