Paul Eggert | 2 Jul 08:39 2015

[tz] [PROPOSED_PATCH] Moldova DST transitions were off by an hour

* NEWS: Moldova starts and ends DST at 00:00 UTC, not at 01:00 UTC.
(Thanks to Roman Tudos.)
* europe (Moldova): New rule.
(Europe/Chisinau): Use it.
---
 NEWS   |  5 +++++
 europe | 14 +++++++++++++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 156da23..f0fedbd 100644
--- a/NEWS
+++ b/NEWS
 <at>  <at>  -6,6 +6,11  <at>  <at>  Unreleased, experimental changes

     Uruguay will stop observing DST.  (Thanks to Steffen Thorsen.)

+  Changes affecting past and future time stamps
+
+    Moldova starts and ends DST at 00:00 UTC, not at 01:00 UTC.
+    (Thanks to Roman Tudos.)
+
   Changes affecting installed data files

     Data entries have been simplified for Atlantic/Canary, Europe/Simferopol,
diff --git a/europe b/europe
index a5e95bb..7cbf1f8 100644
--- a/europe
+++ b/europe
 <at>  <at>  -1763,6 +1763,18  <at>  <at>  Zone	Europe/Malta	0:58:04 -	LMT	1893 Nov  2  0:00s # Valletta
(Continue reading)

Roman Tudos | 30 Jun 21:51 2015
Picon

[tz] Europe/Chisinau Timezone

Please be informed that according Moldavian Law dst start on last last Sunday of March end on last sunday of October

at 02:00 to 03:00 and at 03:00 to 02:00 respectively



2015Sun, 29 Mar, 02:00EETEEST+1 hour (DST start)UTC+3h Sun, 25 Oct, 03:00EESTEET-1 hour (DST end)UTC+2h2016Sun, 27 Mar, 02:00EETEEST+1 hour (DST start)UTC+3h Sun, 30 Oct, 03:00EESTEET-1 hour (DST end)UTC+2h2017Sun, 26 Mar, 02:00EETEEST+1 hour (DST start)UTC+3h Sun, 29 Oct, 03:00EESTEET-1 hour (DST end)UTC+2h2018Sun, 25 Mar, 02:00EETEEST+1 hour (DST start)UTC+3h Sun, 28 Oct, 03:00EESTEET-1 hour (DST end)UTC+2h


Please take consideration for changes in tzdata 



PS. Sorry for my english
--
Vita sine libertate, nihil
Steffen Thorsen | 30 Jun 23:44 2015

[tz] Uruguay out of DST

According to media in Uruguay, it looks like they will not be using DST 
the coming summer:
http://www.elobservador.com.uy/gobierno-resolvio-que-no-habra-cambio-horario-verano-n656787
http://www.republica.com.uy/este-ano-no-se-modificara-el-huso-horario-en-uruguay/523760/

It is a bit unclear if this is just this coming summer, or a permanent 
change.

Our English summary (will be updated when we know more details):
http://www.timeanddate.com/news/time/uruguay-stops-dst-2015.html

Best regards,
Steffen Thorsen - timeanddate.com

Hank W. | 30 Jun 10:54 2015
Picon

[tz] Trivia: Sunrise in Santiago

Today, 30 June 2015, is the latest sunrise of winter in Santiago, Chile.  I was curious about what that latest time is, not only because this is Chile’s first winter on “permanent” Summer Time, but also because UTC-3 is so far from Santiago’s LMT of UTC-4.713.

Sunrise in Santiago today will be at 08:48 CLST!

 

Hank Wisniewski of Austin, Texas, U.S.A.

“’Tis better to be silent and thought the fool than to speak and dispel all doubt.” -unknown

Paul Eggert | 28 Jun 18:00 2015

[tz] Best practices for upcoming leap second event

If you're responsible for proper timekeeping you probably have already thought 
about the upcoming leap second at the end of Tuesday 2015-06-30 UTC.  This is 
the first leap second in eighteen years that has fallen on a non-holiday 
weekday.  It might not hurt to run through your checklist again, and (if you 
haven't already done so) compare it to the checklist recommended by GPS.GOV, 
NAVCEN, NCCIC, NIST, and USNO.  You can find that checklist here:

http://www.gps.gov/news/2015/05/leap-second/2015-best-practices-for-leap-second.pdf

The new leap second has been in the tz database since release 2015a dated 
2015-01-29 22:35:20 -0800, so if you're newer than that you should be good as 
far as tz is concerned.  In the typical case where you're not using tz's 
leap-second support, you don't need to worry about tz at all.

Howard Hinnant | 21 Jun 00:34 2015
Picon

[tz] Three more tweaks

Hi,

I’ve surveyed the entire database for transitions 24h or less apart with one of them being a faux
transition.  I found only 6.  You just eliminated the first.  Two more are in Europe/Istanbul and I see no way
to eliminate the faux transition.  Here are the remaining 3 with explanations and fixes:

———————————

Europe/Simferopol 1996 Mar 31:

1996-03-30 20:59:59u = 1996-03-30 23:59:59 MSK  // 03:00:00   E-Eur  MSK/MSD
1996-03-30 21:00:00u = 1996-03-31 01:00:00 MSD  // 03:00:00   E-Eur  MSK/MSD

And then 3h later:

1996-03-30 23:59:59u = 1996-03-31 03:59:59 MSD  // 03:00:00   E-Eur  MSK/MSD
1996-03-31 00:00:00u = 1996-03-31 04:00:00 MSD  // 03:00:00   01:00  MSD

The second faux transition can be combined with the first actual transition with:

diff --git a/europe b/europe
index 630c234..1242927 100644
--- a/europe
+++ b/europe
 <at>  <at>  -2364,7 +2364,7  <at>  <at>  Zone Europe/Simferopol     2:16:24 -      LMT     1880
 # changed in May.
                         2:00   E-Eur   EE%sT   1994 May
 # From IATA SSIM (1994/1997), which also says that Kerch is still like Kiev.
-                        3:00   E-Eur   MSK/MSD 1996 Mar 31  3:00s
+                        3:00   E-Eur   MSK/MSD 1996 Mar 31  0:00s
                         3:00   1:00    MSD     1996 Oct 27  3:00s
 # IATA SSIM (1997-09) says Crimea switched to EET/EEST.
 # Assume it happened in March by not changing the clocks.

———————————

Europe/Sofia 1982 Sep 26:

1982-09-25 22:59:59u = 1982-09-26 01:59:59 EEST  // 02:00:00   Bulg   EE%sT
1982-09-25 23:00:00u = 1982-09-26 02:00:00 EEST  // 02:00:00   C-Eur  EE%sT

And then 1h later:

1982-09-25 23:59:59u = 1982-09-26 02:59:59 EEST  // 02:00:00   C-Eur  EE%sT
1982-09-26 00:00:00u = 1982-09-26 02:00:00 EET   // 02:00:00   C-Eur  EE%sT

The first faux transition can be merged with the second actual transition with:

diff --git a/europe b/europe
index 630c234..f096de5 100644
--- a/europe
+++ b/europe
 <at>  <at>  -845,7 +845,7  <at>  <at>  Zone        Europe/Sofia    1:33:16 -       LMT     1880
                        1:00    C-Eur   CE%sT   1945
                        1:00    -       CET     1945 Apr  2  3:00
                        2:00    -       EET     1979 Mar 31 23:00
-                       2:00    Bulg    EE%sT   1982 Sep 26  2:00
+                       2:00    Bulg    EE%sT   1982 Sep 26  3:00
                        2:00    C-Eur   EE%sT   1991
                        2:00    E-Eur   EE%sT   1997
                        2:00    EU      EE%sT

———————————

Europe/Tallinn 1999 Nov  1:

1999-10-31 00:59:59u = 1999-10-31 03:59:59 EEST  // 02:00:00   EU   EE%sT 
1999-10-31 01:00:00u = 1999-10-31 03:00:00 EET   // 02:00:00   EU   EE%sT 

And then 21h later:

1999-10-31 21:59:59u = 1999-10-31 23:59:59 EET  // 02:00:00   EU    EE%sT 
1999-10-31 22:00:00u = 1999-11-01 00:00:00 EET  // 02:00:00         EET

The second faux transition can be combined with the first actual transition with:

diff --git a/europe b/europe
index 630c234..c788416 100644
--- a/europe
+++ b/europe
 <at>  <at>  -1084,7 +1084,7  <at>  <at>  Zone      Europe/Tallinn  1:39:00 -       LMT     1880
                        3:00    Russia  MSK/MSD 1989 Mar 26  2:00s
                        2:00    1:00    EEST    1989 Sep 24  2:00s
                        2:00    C-Eur   EE%sT   1998 Sep 22
-                       2:00    EU      EE%sT   1999 Nov  1
+                       2:00    EU      EE%sT   1999 Oct  31  4:00
                        2:00    -       EET     2002 Feb 21
                        2:00    EU      EE%sT

Thanks,
Howard

Howard Hinnant | 20 Jun 21:45 2015
Picon

[tz] Unnecessary faux transition in Atlantic/Canary 1980 Sep/28

Hi,

I wouldn’t call this a bug, but a potential database inefficiency.

I’m working on a TZ parser and using it to explore the timezone transitions as specified by the timezone
database.  I’m looking at the Atlantic/Canary transition on 1980 Sep 28 0:00s.  At this time the timezone
transitions from a permanent saving of 1:00 and abbreviation of WEST to a rule based savings specified by EU:

1980-09-27 23:59:59u = 1980-09-28 00:59:59 WEST // as specified by 0:00 1:00 WEST
1980-09-28 00:00:00u = 1980-09-28 01:00:00 WEST // as specified by 0:00 EU   WE%sT

I.e. there is no change in offset, savings, or abbreviation.  And then an hour later EU specifies a savings
and abbreviation change:

1980-09-28 00:59:59u = 1980-09-28 01:59:59 WEST
1980-09-28 01:00:00u = 1980-09-28 01:00:00 WET

My observation is that this is a lot of transitions for one night.  Would it not be better to delay the
transition from "0:00 1:00 WEST” to "0:00 EU   WE%sT” by one hour, and thus have only one transition
instead of two?  Here is a change that does so:

diff --git a/europe b/europe
index c64c41b..630c234 100644
--- a/europe
+++ b/europe
 <at>  <at>  -2922,7 +2922,7  <at>  <at>  Zone      Africa/Ceuta    -0:21:16 -      LMT     1901
 Zone   Atlantic/Canary -1:01:36 -      LMT     1922 Mar # Las Palmas de Gran C.
                        -1:00   -       CANT    1946 Sep 30  1:00 # Canaries T
                         0:00   -       WET     1980 Apr  6  0:00s
-                        0:00   1:00    WEST    1980 Sep 28  0:00s
+                        0:00   1:00    WEST    1980 Sep 28  1:00s
                         0:00   EU      WE%sT
 # IATA SSIM (1996-09) says the Canaries switch at 2:00u, not 1:00u.
 # Ignore this for now, as the Canaries are part of the EU.

Howard

Paul Eggert | 13 Jun 23:22 2015

[tz] [tz-announce] 2015e release of tz code and data available

The 2015e release of the tz code and data is available.  It reflects the 
following changes, which were either circulated on the tz mailing list or are 
relatively minor technical or administrative changes:

   Changes affecting future time stamps

     Morocco will suspend DST from 2015-06-14 03:00 through 2015-07-19 02:00,
     not 06-13 and 07-18 as we had guessed.  (Thanks to Milamber.)

     Assume Cayman Islands will observe DST starting next year, using US rules.
     Although it isn't guaranteed, it is the most likely.

   Changes affecting data format

     The file 'iso3166.tab' now uses UTF-8, so that its entries can better
     spell the names of Åland Islands, Côte d'Ivoire, and Réunion.

   Changes affecting code

     When displaying data, tzselect converts it to the current locale's
     encoding if the iconv command works.  (Problem reported by random832.)

     tzselect no longer mishandles Dominica, fixing a bug introduced
     in Release 2014f.  (Problem reported by Owen Leibman.)

     zic -l no longer fails when compiled with -DTZDEFAULT=\"/etc/localtime\".
     This fixes a bug introduced in Release 2014f.
     (Problem reported by Leonardo Chiquitto.)

Here are links to the release files:

   ftp://ftp.iana.org/tz/releases/tzcode2015e.tar.gz
   ftp://ftp.iana.org/tz/releases/tzdata2015e.tar.gz

The files are also available via HTTP as follows:

   http://www.iana.org/time-zones/repository/releases/tzcode2015e.tar.gz
   http://www.iana.org/time-zones/repository/releases/tzdata2015e.tar.gz

As usual, links to the latest release files are here:

   http://www.iana.org/time-zones/repository/tzcode-latest.tar.gz
   http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz

   ftp://ftp.iana.org/tz/tzcode-latest.tar.gz
   ftp://ftp.iana.org/tz/tzdata-latest.tar.gz

Each release file has a GPG signature, which can be retrieved by appending 
".asc" to the above URLs.  Copies of these signatures are appended to this message.

This release corresponds to commit 503ee68905da57fc52df74c889aedf4e67e59a79 
dated Sat Jun 13 10:56:02 2015 -0700 and tagged '2015e' in the experimental 
github repository at <https://github.com/eggert/tz>.

Here are the SHA-512 checksums for the release
files:

fdc568a68f4876b967b39e21fa53f063dc5756e886e2a273cc046d5a014eb517e9c91eb6e03d18c94a89ce48578868aed710790415c500188fce4e4add0ce7ca 

tzcode2015e.tar.gz
86498190a20c5c67827aa75f7e9c6aa6c19d58a88a70425ce70d5ae7cea42dc7386eb2867fa455fcfcdedc6a105ad70fbbdc7c27c7a58a51bd21d76a135983ce 
  tzdata2015e.tar.gz

Here are the GPG checksums for the release files:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABAgAGBQJVfG8zAAoJEO2X6Q5iqn4014YP/jGiiK7VYqstDoQNm33/pOwx
WlwTSkzByrhx0whaaAlTQ+j61q2MdZaDlpdDd4CEGN1vWaiI26MOEbZEKVpW5ogm
xKGL9esGltoc3jelmWJTVf0e03l+k0+zDcnBq+58Pi5rkgM/WVFyZBDyCT5HGLq+
NPaHLHU4dlWtwpyd9Mr4eMb6DPEM4zbTK2NbHh/uf+ODG8F1VW8FP63N/hqq4Y/q
4H+ngf9jJxw73pBri/WBmidSxLWhhc+woezhKqbCThto4Jhoehlp3txIqBmAoN3G
AwppaGiHV6PYheLqloCDmdxABMoS95tznuk8eL2FF69IP541kaOchHvKCnbEf6gu
Sdr388Ayli/C98ZQknwzNWVlfKKW+d+nidS5iGyEHRpI/42RPemGh5kgYmZucZpH
DRIbujsi9usxjrazWC8oGf7WH6D6ZmsUusl7pj071YnU0gpXyVSk9GUoMWIp3Wxc
CSHJWxF6lkxOmHDqZFHhcVyyKlPHXFpWpDUPhu/QTi7oiSQeXRoP9BQAz07oN8WS
69JUSxCvkFANkFxnx6knsDBwduFUqiZ209WwV0R72DI/7Gi6OuubXUvgcQfJOHab
wOyEInI32uHRKxEaQuDmu1PSzlur0iNGH3PtuQzgwLlMM0KXsRbLBhOO5zP2BgQ6
zVgFQ9FGlnExUxsBcnTf
=BRRd
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABAgAGBQJVfG8/AAoJEO2X6Q5iqn40ed0P/jn6lgG6tH+C2Xv2DYz5buRK
CMDoGidznyzDuPSNgSPRaDetoKQ/6iVzEIgHYwBxBtmKmPXUgSY8rJPCabSLNKWK
T3o7f8aREnIcfexmct/4DEeUOXePUIbSHnX6Noy3AmSvIsKT8ZahEpnELKgWFQD8
0EEOlck1rTTpEi9G2RATUwr430ii1OguIt0sKYycTvT1VFdihKWoFhgV9ydgaMh2
88he3Ornt4xd4/b278IJl3GI0WWVbVl2A+ziRPAkl3AH7iW7mTcv+/8i3u7txVW+
zB47UHOfV9jpiecLUQDw42KZJTlS+AkbgCitrpL++bZz1WQHWP9JkpgvAR8bdkBf
WPNvcPXiG0I6Vtl2ZZrc2WXi9L22m0xIJA2so4vpBwBIMkTnaFa6VthLGy9UgHpA
wteG6OogfdNm7fv+GhuRUNuHtd5TP5HdywhWMrMtGqgOvkEm/lF6tRMd12Wm57IW
u72Gv3RrJILBuOvBvWPZJMNsjc8Uj1U+dhKa8Z51VHA85ZyiRM3mQr8g+1WETH/E
sjnj8NgKkh7TL/N5vWJH1M3g1XZ3uofPL1Cbyqg04BGrMytxGAjigzIDbbg5pky+
yFUqR3qm12d9QPlm1xh35qxqYYDXcbiQkXENwGukLRzcc0jdU4BrFpDc1tVgukUg
TmCC2ALEcxWWPEc1vtUG
=gO91
-----END PGP SIGNATURE-----
_______________________________________________
tz-announce mailing list
tz-announce <at> iana.org
https://mm.icann.org/mailman/listinfo/tz-announce
Milamber | 8 Jun 19:44 2015
Picon

[tz] Morocco DST Interruption during Ramadan 2015


Hello,

(Google Translation)
The current time of Morocco (GMT + 1) will be suspended from next Sunday 
until July 19, announced Monday the Ministry of Civil Service and 
Modernisation of Administration.

The hour will thus be delayed 60 minutes Sunday, June 14 at 3:00, the 
ministry said in a statement, adding that the time will be advanced 
again 60 minutes Sunday, July 19, 2015 at 2:00.

The move comes under 2.12.126 Decree of 26 Jumada I 1433 (18 April 2012) 
and the decision of the Head of Government of 16 N. 3-29-15 Chaaban 1435 
(4 June 2015).

Source (french):
http://lnt.ma/le-maroc-reculera-dune-heure-le-dimanche-14-juin/
(currently the official notice isn't publish on official government 
website  http://www.mmsp.gov.ma)

I thinks that the new rule for all new ramadan period is the time change 
the Sunday (like the DST) or not the Saturday.

Milamber

Note:

Current prediction in tzdata:
Africa/Casablanca  Sat Jun 13 01:59:59 2015 UT = Sat Jun 13 02:59:59 
2015 WEST isdst=1 gmtoff=3600
Africa/Casablanca  Sat Jun 13 02:00:00 2015 UT = Sat Jun 13 02:00:00 
2015 WET isdst=0 gmtoff=0
Africa/Casablanca  Sat Jul 18 01:59:59 2015 UT = Sat Jul 18 01:59:59 
2015 WET isdst=0 gmtoff=0
Africa/Casablanca  Sat Jul 18 02:00:00 2015 UT = Sat Jul 18 03:00:00 
2015 WEST isdst=1 gmtoff=3600

Howard Hinnant | 7 Jun 03:36 2015
Picon

[tz] Possible bug in the tz database

I’m new to this list, so please forgive me for my inexperience and lack of history.

I am concerned about the timezone America/North_Dakota/Beula:

Early of the local morning of 2010-11-07 the local timezone GMTOFF changed from -7:00 to -6:00, and the
timezone abbreviation changed from MDT to CST.  I am not questioning this historical fact.  Rather I am
concerned about exactly when it happened and does the tz database accurately reflect this event.

Here are the relevant entries today:

Zone America/North_Dakota/Beulah -6:47:07 - LMT	1883 Nov 18 12:12:53
			-7:00	US	M%sT	2010 Nov  7  2:00
			-6:00	US	C%sT

Which says at 2:00am local time on 2010/Nov/07 the change from MDT to CST occurs.  Local time is defined by
GMTOFF == -7:00 + US timezone rules for 2010.

Or in other words 2:00am + 7:00 + any daylight savings time adjustment.

I’m sure I’m preaching to the choir with this audience.

I think there is no dispute that:

    2010-11-07 01:59:59 MDT == 2010-11-07 07:59:59 UTC

At this point in time the GMTOFF == -7:00 and in the US rule SAVE == 1:00 for a total offset of -6:00.

However according to US rules for this date, the local clock ticks from 01:59:59 MDT to 01:00:00 MST.  To
reach 2:00am local time we need to wait another hour:

    2010-11-07 02:00:00 MST == 2010-11-07 09:00:00 UTC

According to US time zone rules (speaking about the recognized practice in the US, not about tz database
rules), there was no 2010-11-07 02:00:00 MDT.  It simply did not exist.

So 2010-11-07 02:00:00 local time in US rules is unambiguously a standard time, not a daylight savings
time.  Whereas the times [01:00:00, 01:59:59] *are* ambiguous (or more accurately described with a
half-open range: [01:00:00, 02:00:00).

Since 2010-11-07 02:00:00 is unambiguously a standard time, the database could read like this with no
change in behavior:

Zone America/North_Dakota/Beulah -6:47:07 - LMT	1883 Nov 18 12:12:53
			-7:00	US	M%sT	2010 Nov  7  2:00s
			-6:00	US	C%sT

But this data indicates that local time behaves as follows that morning:

    2010-11-07 01:59:59 MDT = 2010-11-07 07:59:59 UTC
    2010-11-07 01:00:00 MST = 2010-11-07 08:00:00 UTC
    2010-11-07 01:00:01 MST = 2010-11-07 08:00:01 UTC
    …
    2010-11-07 01:59:59 MST = 2010-11-07 08:59:59 UTC
    2010-11-07 03:00:00 CST = 2010-11-07 09:00:00 UTC
    2010-11-07 03:00:01 CST = 2010-11-07 09:00:01 UTC

However I believe the intended behavior is:

    2010-11-07 01:59:59 MDT = 2010-11-07 07:59:59 UTC
    2010-11-07 02:00:00 CST = 2010-11-07 08:00:00 UTC
    2010-11-07 02:00:01 CST = 2010-11-07 08:00:01 UTC

I believe the tz database can be changed to give the desired behavior with:

diff --git a/northamerica b/northamerica
index 88423e6..aeaf12c 100644
--- a/northamerica
+++ b/northamerica
 <at>  <at>  -371,7 +371,7  <at>  <at>  Zone America/North_Dakota/New_Salem -6:45:39 - LMT  1883 Nov 18 12:14:21
 # of 6h47'07".

 Zone America/North_Dakota/Beulah -6:47:07 - LMT        1883 Nov 18 12:12:53
-                       -7:00   US      M%sT    2010 Nov  7  2:00
+                       -7:00   US      M%sT    2010 Nov  7  1:00s
                        -6:00   US      C%sT

 # US mountain time, represented by Denver

If I have misinterpreted the meanings of the fields to the tz database in some way, I would appreciate an
education.  I’ve reread all of the man pages and other documentation I can find, and haven’t been able
to rectify this contradiction on my own.

If this is indeed a bug that can be corrected, I am volunteering to detect and correct similar issues
elsewhere in the database and generate a pull request for https://github.com/eggert/tz.

Howard

Paul Eggert | 6 Jun 08:30 2015

[tz] NTSB investigation derailed by time zone labyrinth

When the chair of the U.S. National Transportation Safety Board appeared before 
the House Transportation and Infrastructure Committee this week, he was asked 
"Could you just tell us again in plain English why we don't know if this 
operator was on the phone three weeks after the accident?"  He had trouble 
answering, because although the NTSB has detailed timestamped data for the 
engineer's cell phone records, and they have physical access to the phone and 
the phone's passwords, they can't figure out the data's time zones.  The cell 
phone companies don't know either.

My sources:

Jaffe E. We still basically have no idea what happened with the Amtrak 188 
derailment. CityLab 2015-06-04. 
http://www.citylab.com/commute/2015/06/we-still-basically-have-no-idea-what-happened-with-the-amtrak-188-derailment/394934/

Nixon R. Phone data labyrinth hinders investigation of Amtrak derailment. New 
York Times 2015-06-05. 
http://www.nytimes.com/2015/06/06/us/inquiry-into-amtrak-derailment-is-slowed-by-a-maze-of-cellphone-data.html


Gmane