On 5/7/19 3:53 AM, Manjusri Mahendran -X (manjmahe - INFOSYS LIMITED at Cisco) wrote:
We have issues on Call Manager running on EST timezone.
Could see that there is no replacement added for deprecated timezones EST, HST and MST whereas other deprecated timezones such as “Brazil East” and “Singapore” has a replacement.
How are these three timezones different from the rest of deprecated ones.?
They aren't deprecated. EST, HST, and MST are still in tzdb, in the 'northamerica' file. They've been there since 2005. It sounds like you've run into an issue that is downstream from tzdb.
I think perhaps the confusion may stem from the list on Wikipedia, which I occasionally contribute to: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones Wikipedia isn't authoritative, of course, but it is cited often. The legend at the top defines the terms used, but I could change the term "deprecated" to something else if it would be helpful. I added the status column awhile back to encourage people to use the Area/Locality forms of names instead of the older ones. I just added some additional notes to the ones Manjusri cited to suggest alternatives. -Matt ________________________________ From: tz <tz-bounces@iana.org> on behalf of Paul Eggert <eggert@cs.ucla.edu> Sent: Tuesday, May 7, 2019 12:00 PM To: Manjusri Mahendran -X (manjmahe - INFOSYS LIMITED at Cisco) Cc: Time Zone Mailing List Subject: Re: [tz] Issue with EST timezone On 5/7/19 3:53 AM, Manjusri Mahendran -X (manjmahe - INFOSYS LIMITED at Cisco) wrote:
We have issues on Call Manager running on EST timezone.
Could see that there is no replacement added for deprecated timezones EST, HST and MST whereas other deprecated timezones such as “Brazil East” and “Singapore” has a replacement.
How are these three timezones different from the rest of deprecated ones.?
They aren't deprecated. EST, HST, and MST are still in tzdb, in the 'northamerica' file. They've been there since 2005. It sounds like you've run into an issue that is downstream from tzdb.
On May 7, 2019, at 12:29 PM, Matt Johnson <mj1856@hotmail.com> wrote:
I added the status column awhile back to encourage people to use the Area/Locality forms of names instead of the older ones. I just added some additional notes to the ones Manjusri cited to suggest alternatives.
It now also notes that EST, MST, and HST do *not* have DST, so they shouldn't be used as synonyms for "Eastern time", "Mountain time", or "Hawaii time" unless you're in a location that doesn't observe DST. E.g., EST currently applies to Quintana Roo but not to, for example, any location in the US or Canada, and MST currently applies to most of Arizona but not the rest of the Mountain time zone (HST currently applies to the Hawaii time zone).
On 2019-05-07, at 14:26:06, Guy Harris wrote:
On May 7, 2019, at 12:29 PM, Matt Johnson wrote:
I added the status column awhile back to encourage people to use the Area/Locality forms of names instead of the older ones. I just added some additional notes to the ones Manjusri cited to suggest alternatives.
It now also notes that EST, MST, and HST do *not* have DST, so they shouldn't be used as synonyms for "Eastern time", "Mountain time", or "Hawaii time" unless you're in a location that doesn't observe DST. E.g., EST currently applies to Quintana Roo but not to, for example, any location in the US or Canada, and MST currently applies to most of Arizona but not the rest of the Mountain time zone (HST currently applies to the Hawaii time zone).
Note, just to confuse things, by act of Congress, in the U.S. Daylight Saving time *is* Standard Time: http://www.webexhibits.org/daylightsaving/usc.html Sec. 260a. Advancement of time or changeover dates Duration of period; State exemption During the period commencing at 2 o'clock antemeridian on the first Sunday of April of each year and ending at 2 o'clock antemeridian on the last Sunday of October of each year, the standard time of each zone established by sections 261 to 264 of this title, as modified by section 265 of this title, shall be advanced one hour and such time as so advanced shall for the purposes of such sections 261 to 264, as so modified, be the standard time ... No mention or legal definition of "Daylight Saving". That travesty impelled WWV to cease reporting "Eastern Standard Time" and switch to reporting UTC. -- gil
On May 7, 2019, at 4:59 PM, Paul Gilmartin via tz <tz@iana.org> wrote:
On 2019-05-07, at 14:26:06, Guy Harris wrote:
... Note, just to confuse things, by act of Congress, in the U.S. Daylight Saving time *is* Standard Time: http://www.webexhibits.org/daylightsaving/usc.html
Sure, but that's irrelevant because the term has a plain English meaning in common usage, and that is the way the term is used here. The fact that lawyers speak strangely is not our concern. paul
On 2019-05-07 13:29, Matt Johnson wrote:
I think perhaps the confusion may stem from the list on Wikipedia, which I occasionally contribute to: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
Wikipedia isn't authoritative, of course, but it is cited often. The legend at the top defines the terms used, but I could change the term "deprecated" to something else if it would be helpful.
Legacy would be short and better than [Backward] Compatible.
I added the status column awhile back to encourage people to use the Area/Locality forms of names instead of the older ones. I just added some additional notes to the ones Manjusri cited to suggest alternatives.
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
Matt and Paul, Thanks much for replying and updating the Wikipedia ! We did refer to the wiki yesterday and few other links, one such is https://stackoverflow.com/questions/41672825/which-three-letter-time-zone-id... which cited EST is deprecated Looks like this issue is seen since OS RPM from Redhat "tzdata" is missing rules for EST timezone. Anyways , we suggested our users to go with alternatives updated last night. -Thanks again Manjusri From: Matt Johnson <mj1856@hotmail.com> Sent: Wednesday, May 8, 2019 12:59 AM To: Paul Eggert <eggert@cs.ucla.edu>; Manjusri Mahendran -X (manjmahe - INFOSYS LIMITED at Cisco) <manjmahe@cisco.com> Cc: Time Zone Mailing List <tz@iana.org> Subject: Re: [tz] Issue with EST timezone I think perhaps the confusion may stem from the list on Wikipedia, which I occasionally contribute to: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones Wikipedia isn't authoritative, of course, but it is cited often. The legend at the top defines the terms used, but I could change the term "deprecated" to something else if it would be helpful. I added the status column awhile back to encourage people to use the Area/Locality forms of names instead of the older ones. I just added some additional notes to the ones Manjusri cited to suggest alternatives. -Matt ________________________________ From: tz <tz-bounces@iana.org<mailto:tz-bounces@iana.org>> on behalf of Paul Eggert <eggert@cs.ucla.edu<mailto:eggert@cs.ucla.edu>> Sent: Tuesday, May 7, 2019 12:00 PM To: Manjusri Mahendran -X (manjmahe - INFOSYS LIMITED at Cisco) Cc: Time Zone Mailing List Subject: Re: [tz] Issue with EST timezone On 5/7/19 3:53 AM, Manjusri Mahendran -X (manjmahe - INFOSYS LIMITED at Cisco) wrote:
We have issues on Call Manager running on EST timezone.
Could see that there is no replacement added for deprecated timezones EST, HST and MST whereas other deprecated timezones such as "Brazil East" and "Singapore" has a replacement.
How are these three timezones different from the rest of deprecated ones.?
They aren't deprecated. EST, HST, and MST are still in tzdb, in the 'northamerica' file. They've been there since 2005. It sounds like you've run into an issue that is downstream from tzdb.
Manjusri Mahendran -X (manjmahe - INFOSYS LIMITED at Cisco) wrote:
Looks like this issue is seen since OS RPM from Redhat "tzdata" is missing rules for EST timezone.
That's odd, as the tzdata package has the EST file on all the Red Hat machines I just now checked: On RHEL 6.10: $ rpm -qf /usr/share/zoneinfo/EST tzdata-2018i-1.el6.noarch On RHEL 7.6: $ rpm -qf /usr/share/zoneinfo/EST tzdata-2018i-1.el7.noarch On Fedora 30: $ rpm -qf /usr/share/zoneinfo/EST tzdata-2019a-1.fc30.noarch Perhaps your installation went haywire somehow?
Hi Paul, We do have the EST file. However, when we run zdump on it, it just displays the entry for 1901 and 2038 zdump -v /usr/share/zoneinfo/EST /usr/share/zoneinfo/EST Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 15:45:52 1901 EST isdst=0 gmtoff=-18000 /usr/share/zoneinfo/EST Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 15:45:52 1901 EST isdst=0 gmtoff=-18000 /usr/share/zoneinfo/EST Mon Jan 18 03:14:07 2038 UTC = Sun Jan 17 22:14:07 2038 EST isdst=0 gmtoff=-18000 /usr/share/zoneinfo/EST Tue Jan 19 03:14:07 2038 UTC = Mon Jan 18 22:14:07 2038 EST isdst=0 gmtoff=-18000 Because of above, we don’t get any DST changes applicable for EST for 2019. Is the output expected (which looks like as per https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)? Any idea since when it changed or was it this way all the time. Regards, Prakash -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Thursday, May 9, 2019 10:23 AM To: Manjusri Mahendran -X (manjmahe - INFOSYS LIMITED at Cisco) <manjmahe@cisco.com>; Matt Johnson <mj1856@hotmail.com> Cc: Time Zone Mailing List <tz@iana.org>; Prakash Mishra -X (prakasmi - INFOSYS LIMITED at Cisco) <prakasmi@cisco.com> Subject: Re: [tz] Issue with EST timezone Manjusri Mahendran -X (manjmahe - INFOSYS LIMITED at Cisco) wrote:
Looks like this issue is seen since OS RPM from Redhat "tzdata" is missing rules for EST timezone.
That's odd, as the tzdata package has the EST file on all the Red Hat machines I just now checked: On RHEL 6.10: $ rpm -qf /usr/share/zoneinfo/EST tzdata-2018i-1.el6.noarch On RHEL 7.6: $ rpm -qf /usr/share/zoneinfo/EST tzdata-2018i-1.el7.noarch On Fedora 30: $ rpm -qf /usr/share/zoneinfo/EST tzdata-2019a-1.fc30.noarch Perhaps your installation went haywire somehow?
On 5/9/19 12:02 AM, Prakash Mishra -X (prakasmi - INFOSYS LIMITED at Cisco) wrote:
we don’t get any DST changes applicable for EST for 2019.
This is exactly the behavior I expect. "EST" means Eastern Standard Time with no daylight-saving, such as the time observed in Jamaica. That's what it's always meant in tzdb, ever since it was introduced.
On May 9, 2019, at 12:02 AM, Prakash Mishra -X (prakasmi - INFOSYS LIMITED at Cisco) via tz <tz@iana.org> wrote:
We do have the EST file. However, when we run zdump on it, it just displays the entry for 1901 and 2038
That's what it's supposed to do...
Because of above, we don’t get any DST changes applicable for EST for 2019.
...because it's defined to be a "5 hours west of UTC, all year round" setting.
Is the output expected (which looks like as per https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)?
Yes.
Any idea since when it changed or was it this way all the time.
It was this way all the time.
participants (8)
-
Brian Inglis -
Guy Harris -
Manjusri Mahendran -X (manjmahe - INFOSYS LIMITED at Cisco) -
Matt Johnson -
Paul Eggert -
Paul Gilmartin -
Paul.Koning＠dell.com -
Prakash Mishra -X (prakasmi - INFOSYS LIMITED at Cisco)