[IANA Time Zone Database change] case: 2014-0929-0685: Russia government changed time-zone to permanent winter time
Hello IANA team, This is Mengzhe Hu from Juniper Networks Advanced TAC. Here we are importing the IANA Time Zone Database to Junos referring to the two pages below: Juniper page:http://www.juniper.net/documentation/en_US/junos13.3/topics/task/configurati... IANA page: http://www.iana.org/time-zones But from the latest tzdata-latest.tar.gz<ftp://ftp.iana.org/tz/tzdata-latest.tar.gz> , we can't find the corresponding change reflecting the Moscow, Russia government time zone change. Please refer to the following page: http://www.timeanddate.com/time/change/russia/moscow We have done the following tests using your latest database: First I compiled new tzdata downloaded from iana.org and added use-imported-time-zones command in configuration. After i run my test. Set date to Oct 26 01:59 a.m. and waited for 02:00a.m. At that point time must be moved back to 01:00a.m. but it doesn't happen. root@MX960-R31-RE0> set date 201410260159.00 Sun Oct 26 01:59:00 MSK 2014 root@MX960-R31-RE0> show system uptime Current time: 2014-10-26 01:59:05 MSK System booted: 2014-10-22 00:23:26 MSK (4d 02:35 ago) Protocols started: 2014-10-22 00:24:46 MSK (4d 02:34 ago) Last configured: 2014-10-25 15:00:15 MSK (11:58:50 ago) by apinaev 1:59AM up 4 days, 2:36, 1 user, load averages: 0.02, 0.04, 0.00 root@MX960-R31-RE0> show system uptime Current time: 2014-10-26 01:59:57 MSK System booted: 2014-10-22 00:23:26 MSK (4d 02:36 ago) Protocols started: 2014-10-22 00:24:46 MSK (4d 02:35 ago) Last configured: 2014-10-25 15:00:15 MSK (11:59:42 ago) by apinaev 1:59AM up 4 days, 2:37, 1 user, load averages: 0.21, 0.08, 0.02 root@MX960-R31-RE0> show system uptime Current time: 2014-10-26 02:00:03 MSK System booted: 2014-10-22 00:23:26 MSK (4d 02:36 ago) Protocols started: 2014-10-22 00:24:46 MSK (4d 02:35 ago) Last configured: 2014-10-25 15:00:15 MSK (11:59:48 ago) by apinaev 2:00AM up 4 days, 2:37, 1 user, load averages: 0.17, 0.08, 0.02<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<should change to 1:00 AM Please look into the issue with high priority because the timezone change will happen in Oct 26th which is 6 days from now. Regards, Mengzhe
Mengzhe, You are very likely running into a similar issue as one addressed earlier on this list; namely, since there are two instances of 01:59 on the date in question, your set date operation is assuming you mean the second one, after the transition has already occurred. Please see: http://mm.icann.org/pipermail/tz/2014-August/021547.html http://mm.icann.org/pipermail/tz/2014-September/021550.html You can get around this by setting the date according to UTC, one minute before the expected changeover: date -s "Sat Oct 25 21:59:00 UTC 2014" -u -- Tim Parenti On 20 October 2014 11:31, Mengzhe Hu <mhu@juniper.net> wrote:
Hello IANA team,
This is Mengzhe Hu from Juniper Networks Advanced TAC.
Here we are importing the IANA Time Zone Database to Junos referring to the two pages below: Juniper page: *http://www.juniper.net/documentation/en_US/junos13.3/topics/task/configurati... <http://www.juniper.net/documentation/en_US/junos13.3/topics/task/configurati...> IANA page: *http://www.iana.org/time-zones* <http://www.iana.org/time-zones>
But from the latest tzdata-latest.tar.gz <ftp://ftp.iana.org/tz/tzdata-latest.tar.gz> , we can’t find the corresponding change reflecting the Moscow, Russia government time zone change. Please refer to the following page: *http://www.timeanddate.com/time/change/russia/moscow* <http://www.timeanddate.com/time/change/russia/moscow>
We have done the following tests using your latest database:
First I compiled new tzdata downloaded from iana.org and added use-imported-time-zones command in configuration. After i run my test. Set date to Oct 26 01:59 a.m. and waited for 02:00a.m. At that point time must be moved back to 01:00a.m. but it doesn't happen.
root@MX960-R31-RE0> set date 201410260159.00 Sun Oct 26 01:59:00 MSK 2014
root@MX960-R31-RE0> show system uptime Current time: 2014-10-26 01:59:05 MSK System booted: 2014-10-22 00:23:26 MSK (4d 02:35 ago) Protocols started: 2014-10-22 00:24:46 MSK (4d 02:34 ago) Last configured: 2014-10-25 15:00:15 MSK (11:58:50 ago) by apinaev 1:59AM up 4 days, 2:36, 1 user, load averages: 0.02, 0.04, 0.00
root@MX960-R31-RE0> show system uptime Current time: 2014-10-26 01:59:57 MSK System booted: 2014-10-22 00:23:26 MSK (4d 02:36 ago) Protocols started: 2014-10-22 00:24:46 MSK (4d 02:35 ago) Last configured: 2014-10-25 15:00:15 MSK (11:59:42 ago) by apinaev 1:59AM up 4 days, 2:37, 1 user, load averages: 0.21, 0.08, 0.02
root@MX960-R31-RE0> show system uptime Current time: 2014-10-26 02:00:03 MSK System booted: 2014-10-22 00:23:26 MSK (4d 02:36 ago) Protocols started: 2014-10-22 00:24:46 MSK (4d 02:35 ago) Last configured: 2014-10-25 15:00:15 MSK (11:59:48 ago) by apinaev 2:00AM up 4 days, 2:37, 1 user, load averages: 0.17, 0.08, 0.02<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<should change to 1:00 AM
Please look into the issue with high priority because the timezone change will happen in Oct 26th which is 6 days from now.
Regards, Mengzhe
<<On Tue, 21 Oct 2014 17:58:39 -0400, Tim Parenti <tim@timtimeonline.com> said:
You can get around this by setting the date according to UTC, one minute before the expected changeover: date -s "Sat Oct 25 21:59:00 UTC 2014" -u
On FreeBSD (and therefore likely on JunOS as well) that command would be 'date -u 201410252159.00'. It appears that the tzcode version of the date command (which bears a Berkeley copyright notice) does not support a -s flag either. -GAWollman
participants (3)
-
Garrett Wollman -
Mengzhe Hu -
Tim Parenti