- tz - lists.iana.org

DST in Palestine will start one week later
by Even Scharning March 29, 2019

March 29, 2019

DST in Palestine will start on 30 March this year, not 23 March as the time zone database predicted. Some references (in Arabic): http://pnn.ps/news/401130 http://palweather.ps/ar/node/50136.html https://ramallah.news/post/123610/%D9%85%D9%88%D8%B9%D8%AF-%D8%A7%D9%84%D8%… Even Scharning https://time.is

9 14

Will there be a 2019b update soon?
by Patsy Franklin March 27, 2019

March 27, 2019

Hi, Since there is now an experimental patch for the 2019a update, will there be a 2019b released soon? What would be the anticipated time frame for the update? Thanks, Patsy

3 2

Europe/Dublin daylight saving time format confusion
by Guruswamy Basavaiah March 27, 2019

March 27, 2019

Hello, Generated timezone files using the below command on release 2018e. zic -L /dev/null -d output_dir -y "sh yearistype.sh" europe zdump show daylight saving flag (isdst=1) is wrongly set for Europe/Dublin. Daylight saving time should start from March 31 and end on October 27. But here it shows reverse. zdump -v /home/basavaia/output_dir/Europe/Dublin | grep 2019 /home/basavaia/output_dir/Europe/Dublin Sun Mar 31 00:59:59 2019 UT = Sun Mar 31 00:59:59 2019 GMT isdst=1 gmtoff=0 /home/basavaia/output_dir/Europe/Dublin Sun Mar 31 01:00:00 2019 UT = Sun Mar 31 02:00:00 2019 IST isdst=0 gmtoff=3600 /home/basavaia/output_dir/Europe/Dublin Sun Oct 27 00:59:59 2019 UT = Sun Oct 27 01:59:59 2019 IST isdst=0 gmtoff=3600 /home/basavaia/output_dir/Europe/Dublin Sun Oct 27 01:00:00 2019 UT = Sun Oct 27 01:00:00 2019 GMT isdst=1 gmtoff=0 Above Behavior is same in 2019a also. If I check the same on 2018a, it gives proper output. zdump -v /home/basavaia/2018a/Europe/Dublin | grep 2019 /home/basavaia/2018a/Europe/Dublin Sun Mar 31 00:59:59 2019 UT = Sun Mar 31 00:59:59 2019 GMT isdst=0 gmtoff=0 /home/basavaia/2018a/Europe/Dublin Sun Mar 31 01:00:00 2019 UT = Sun Mar 31 02:00:00 2019 IST isdst=1 gmtoff=3600 /home/basavaia/2018a/Europe/Dublin Sun Oct 27 00:59:59 2019 UT = Sun Oct 27 01:59:59 2019 IST isdst=1 gmtoff=3600 /home/basavaia/2018a/Europe/Dublin Sun Oct 27 01:00:00 2019 UT = Sun Oct 27 01:00:00 2019 GMT isdst=0 gmtoff=0 Is my understanding correct? And this behavior is introduced in commit 127b4af7219e6df9253b34e390797c5527b8cc66 I am not in this mailing list, please include my email id while responding. -- Guruswamy Basavaiah

2 1

Re: [tz] [tz-announce] 2019a release of tz code and data available
by Paul Eggert March 26, 2019

March 26, 2019

On 3/26/19 6:02 AM, Michael H Deckers wrote: > > In the file NEWS, I read > > Release 20198 - 2019-03-25 22:01:33 -0700 > > instead of > > Release 2019a - 2019-03-25 22:01:33 -0700 > > Maybe a file transfer error? No, it's a typo. Sorry about that. I fixed it as per attached. Thanks for reporting it.

1 0

European Parliament votes to drop DST by 2021, leaving it to member states
by Tim Parenti March 26, 2019

March 26, 2019

The European Parliament has just voted 410-192 in favor of dropping its DST requirement in the EU by 2021. The vote is not the last word on the issue but will form the basis of discussions with EU countries to produce a final law. Under the proposal, each member state would decide amongst three options: - to continue with twice-a-year clock changes, - to stick permanently to summer time, or - to stick permanently to winter time. All member states would need to inform the European Commission of their choice ahead of the proposed switch, by April 2020. They would then coordinate with the bloc's executive so that their decisions do not disrupt the functioning of the single market. The European Commission proposed in September ending the practice after an EU-wide opinion survey showed a large majority in favor of doing so. The survey generated 4.6 million responses, with 84% of respondents wanting to end seasonal clock changes. Critics say the survey was dominated by Germans, who made up 70% of the respondents. https://www.dw.com/en/eu-parliament-votes-to-end-daylight-savings/a-48064185 https://www.rte.ie/news/europe/2019/0326/1038689-eu-daylight-savings/ -- Tim Parenti

5 8

Re: [tz] Proposed changes for Argentina, Jan Mayen, worldtimeengine.com, etc.
by REMI ACIEN March 26, 2019

March 26, 2019

Provenance : Courrier<https://go.microsoft.com/fwlink/?LinkId=550986> pour Windows 10 For Atlantic /Jan Mayen , UTC-1 . It’ s yes .

2 1

[tz-announce] 2019a release of tz code and data available
by Paul Eggert March 26, 2019

March 26, 2019

The 2019a 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: Briefly: Palestine "springs forward" on 2019-03-30 instead of 2019-03-23. Metlakatla "fell back" to rejoin Alaska Time on 2019-01-20 at 02:00. Changes to past and future timestamps Palestine will not start DST until 2019-03-30, instead of 2019-03-23 as previously predicted. Adjust our prediction by guessing that spring transitions will be between 24 and 30 March, which matches recent practice since 2016. (Thanks to Even Scharning and Tim Parenti.) Metlakatla ended its observance of Pacific standard time, rejoining Alaska Time, on 2019-01-20 at 02:00. (Thanks to Ryan Stanley and Tim Parenti.) Changes to past timestamps Israel observed DST in 1980 (08-02/09-13) and 1984 (05-05/08-25). (Thanks to Alois Treindl and Isaac Starkman.) Changes to time zone abbreviations Etc/UCT is now a backward-compatibility link to Etc/UTC, instead of being a separate zone that generates the abbreviation "UCT", which nowadays is typically a typo. (Problem reported by Isiah Meadows.) Changes to code zic now has an -r option to limit the time range of output data. For example, 'zic -r @1000000000' limits the output data to timestamps starting 1000000000 seconds after the Epoch. This helps shrink output size and can be useful for applications not needing the full timestamp history, such as TZDIST truncation; see Internet RFC 8536 section 5.1. (Inspired by a feature request from Christopher Wong, helped along by bug reports from Wong and from Tim Parenti.) Changes to documentation Mention Internet RFC 8536 (February 2019), which documents TZif. tz-link.html now cites tzdata-meta <https://tzdata-meta.timtimeonline.com/>. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2019a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2019a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2019a.tar.lz As usual, links to the latest release files are here: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. 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 14c73382cf95efd5f189379427b7b37ca22b9eff dated 2019-03-25 22:01:33 -0700 and tagged '2019a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 7cc76ce6be4a67c3e1b2222cb632d2de9dabb76899793a938f87a1d4bb20e462cabdae9e3b986aaabaa400795370510095d236dbad5aff4c192d0887f0ecedf5 tzcode2019a.tar.gz d8eb5b2b68abee08bd2b0d2134bce85b5c0aee85168e9697a607604ed5be7d1539ac60fda9b37e0c9c793ef6251978bc250563a0af59497fde775499964bb5aa tzdata2019a.tar.gz 5971d53ceb8cd9e0723d0694c2dca5a3781b9c84bdfef2eb324e9f94fb0b25da263cf59b5429bc77e12e549130aab8c8b1755c34d62bf672c184210c629328f2 tzdb-2019a.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlyZs50ACgkQ7ZfpDmKq fjRR5xAAqsWv2T1beL9TnJ2JaadySGOZiJg3M3RqW8Vm4Dd0ye8Dz8t+YtDtBX1/ 8+xGdlS7LWjwK2EQC6xWhp0EiqpiFjMU1FRGFeAlAOOv8SE0dPRfP9vIeKzCNXKp UwtSrzM5JUX6/iza9UUTlzpwHaEM/gVIfP+sLgT15RJiB84teHro/rpcfOvNRyj1 bteknySCtbPcETe9VW3qH2YgMRtNQgkt/DcJgCvY2qWLsnicWRH9Ec6NhqYLFpuv QwvqC0Odaehrytu+DNhi1wuxt90YHgGHMgIZXtG+kO8eJy2aWFP9zQJ80wVvNqat Xgl6T5AU5ZIdBEQkMnk0EhqFlKYFX/81hEWT0gsMBCzteVFhhQQPPyptUwtL5U17 MX1oVaZbiTbTCqjAjHAJbfW61Fbu9H0wzZhoRLvDqaFfOxQ1HEMh2Ioh+KlJ0nLw +l5dLNed7D/kjRE0ja7Jj+ocCl4Hf1DTQknfqtk1USGctWLZ3WfKHk6jCS0vid7g IrN6POYhZ6kg4NLF1G2pD7tTiog37Kvd/c3FHC76cqbbA5wkye+L/A73xmy0qOlv tp14wxd99ETI5loWgMb5SgRzzeEjNbTrG5AuAOX0qK4Fz3cEdK9/PYYJDSOkueJJ 0DpP9Eo3Kmhhk7E4PheygmX+Vk+Ntutu7jx8r6EFNck/erZrnJs= =kJqF -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlyZs50ACgkQ7ZfpDmKq fjTPrg/9HBD7RK0/e2NQc/IEg0BeZPOG/SsWOo78lQ23UVwqXdXqQz9LJXl9gTqM ENe8Ecknctk6fmfriAYnSydXx/MwWDbze5nmi4p7wzlogL/ctPILJvQbc/T62fDK NpGNwDlaUX/ht7cRG9VO+oun3Zc7efGHJB9UpZDDVZGtq6VT5+AZIryM12XvHfcR g0P+0pZfZu9LI4H0K/JUmNnRRXLoq6/5OsV6+hFlTzS7quVfUu+Vb+gsoUVejXld 77hNvqdAaRBwVW69hjdUL2WJXymQtP/1ZoeOVHskti0HQBFRJsDc4Fhs3Pe5MUWd PXVanz/C0sHhHbTLfHs4wVQvNg4g4OP5nl9DyF+KG2SqfuqWOzfbEs5bc8dGqFCk HLdj7Nd4eQA8x/Xl6OSukE1yzUR8Xkb9GFgTmpHlP7uq/TH2URJdd/ZXhSgPv+u6 bM9ghH9eirnVDPxWxsj0bwkZYHY6eJC8pgLPpXsxBY0ktJD/hqS1IMXOAyPRj9fO uRt7QLcsJW+wx6Q7ggsgTs7cxnq/Pk55S0lcp63mAu960+2XuBy8ffFJp4J2OwqS U6nBCtAZ6ZONKvsoQ4UpIcNfkYEiM3A4XNjn/rL2Jtb0cDA8e0j66/k1vcOc9p6u KQSXvSrhoqGTqhKy03XuQJ7LYhSgtD790sxFOXWS59cs/WcLO+M= =g5BY -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlyZs54ACgkQ7ZfpDmKq fjQOExAAj3bXlkhyxx2pTIt2sEiE687kRa3VOKYeLnSLyWfOSAKFsrEXiPHNGPJ9 Xn9PjUZa7cZ+5IiZoHYr37GbDqs0VdTrnt/SId+fxhv14DoCJsQT2yuji7aWrBnp LOIscrsvvciNk6035bWJjuLZRyDYqm8MKBSBCgKuuFOCCy/mFprW42nzM/L9QK3p vhnDrKnXlDF4pu3J6w5MThZyTbJOD4zqMIMgdfuBLlOjks5smLTVmTN0QTuZyVca Cr8T4+BTGnmMfGkgGCG1/33DZg58q/Q7l8hqKkaK6znErPFk5cCE7S/Ty32hD91o x6YUQNxEYai9nhgirr55mYc4/X4BjiqRA/Dzw+Nbum0AC1OtNijqHmy1frZRyky5 jwFaMWEIxSTKKd/FexqBUuw6KpciEtVM46VCa73VQN5/3RqaXiA7f36zi7HB3flC jdKqmse2yMGASavYRMVvY/LT8TC+DPZ2+8hbHproLmz5y7tFgXh+eSqj+SwKIw/5 SADRjIaTCQS6KUm5syUc0Nu4Oi9fEifdnOJ6WM0/yj2ix40D1dXwRSuja2Tf1sM1 DkO05GH0G3+0zjKMROMKwXM8PahXvePcRuaKROO9Nx+mBZ3MvYpaOORecQ7flJKb GINC0cwwbDiLF/k+ESruOlCZ57D6ChUABptKwiPOrmNcqDRYiOo= =6VXD -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets, this particular release's data entries are also available in a rearguard-format tarball and signature that does not contain such offsets. This is intended to be a temporary transition aid for these parsers. The URLs are: https://web.cs.ucla.edu/~eggert/tz/release/2019a/tzdata2019a-rearguard.tar.… https://web.cs.ucla.edu/~eggert/tz/release/2019a/tzdata2019a-rearguard.tar.… with the following SHA-512 and GPG checksums: 1ebca45c43aaed76fcb8894a5e8321975cc74a272a9e7b83b2f4ca9d5c2c0b4a4de276bd019d95468ce7e6b88d8afdab70b17580071b8a54cdf2218c2bb8a069 tzdata2019a-rearguard.tar.gz -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlyZs50ACgkQ7ZfpDmKq fjTGig//QSof18SghwQoHqUCxUEKhblFyV7+mSzEMdF3J+eSCpt+SsoN75NaLHYm GoBlJkmYFOxnyWjbzvn9dcr9/vHXu0D5P8Bd2NvVEULRSJ/Kb+uOsXsic38Z5Uz6 hJ/9Il/7mAYF23diYLtOuuVoeuKrHhmS/9jzACu6jXMwaXXWfMpbm3NGVLgXNIPe QD93PUq/aQ87OwmysZBhXui0PR5Pakg3nWSj7jTtAKhbRFOZdN5g9OxneYvaCmmC K2s+mvXRnQiImNnTvXavAEWw3Gz3MP7972JYdmd6gm9Q+lfNf1ykbM8Z4KO+rDMk YTfQCrNpAtmGP3TqNgFtzBouQAmjoQ8+Lyh7jjGArxZEpZVle+7zSGOoB/US4otz hrHrzg/6rNmYWL5Xvg8rhgtG0fp8uZABhA0s9gV2Qz8TRnArTUoLoYWiEGpfQ7Vf uHU1947DSMebshg4BYBmLvcEr2/KH7TMholRMllTv5soM7sX3bariejI8u5dcDhk wRyiBZhLJbFd+of6kNeo5jPm9caDOWrp3vq2xryyiN1M9s3gu8BfrBcSI2tE2l6F uOMAuaeNOfuoLuAYghgkXWM1DvZo81ePQXAVW9CIsg+aT1wcCRk0TPRn+OiPjbKQ YS4ULentOrEnxdKfFC1XIJ4JQZuDjhyW2vlkboWhc1zT5a83erc= =bFDj -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

Proposed Change to Maine's Time Zone *No Current Action Needed* Update
by C Yohman March 24, 2019

March 24, 2019

LD 144 http://legislature.maine.gov/legis/bills/display_ps.asp?paper=HP0126&PID=un… Ought Not to Proceed LD 885 http://legislature.maine.gov/legis/bills/display_ps.asp?paper=HP0659&PID=un… Tabled I would expect no changes to Maine's timezone in the meantime.

1 0

Error display in America/Santiago - tzdata2018i
by Pedro Salas Díaz March 19, 2019

March 19, 2019

Hello: I'm Pedro Salas Diaz from Chile , and I'm working in TZ change for my servers timezone. When I compile our timezone, I see that timezone is not displayed correctly. >zdump -v America/Santiago | grep 2019 zdump: warning: zone "America/Santiago" abbreviation "-05" lacks alphabetic at start America/Santiago Sun Apr 7 02:59:59 2019 UTC = Sat Apr 6 23:59:59 2019 -03 isdst=1 America/Santiago Sun Apr 7 03:00:00 2019 UTC = Sat Apr 6 23:00:00 2019 -04 isdst=0 America/Santiago Sun Sep 8 03:59:59 2019 UTC = Sat Sep 7 23:59:59 2019 -04 isdst=0 America/Santiago Sun Sep 8 04:00:00 2019 UTC = Sun Sep 8 01:00:00 2019 -03 isdst=1 I found some errors in our apps, because the TZ is not showed as "CLT" nor "CLST". To resolve this, i modified "southamerica" file (these lines) ********************************************************************************** # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Chile 1927 1931 - Sep 1 0:00 1:00 S Rule Chile 1928 1932 - Apr 1 0:00 0 - Rule Chile 1968 only - Nov 3 4:00u 1:00 S Rule Chile 1969 only - Mar 30 3:00u 0 - Rule Chile 1969 only - Nov 23 4:00u 1:00 S Rule Chile 1970 only - Mar 29 3:00u 0 - Rule Chile 1971 only - Mar 14 3:00u 0 - Rule Chile 1970 1972 - Oct Sun>=9 4:00u 1:00 S Rule Chile 1972 1986 - Mar Sun>=9 3:00u 0 - Rule Chile 1973 only - Sep 30 4:00u 1:00 S Rule Chile 1974 1987 - Oct Sun>=9 4:00u 1:00 S Rule Chile 1987 only - Apr 12 3:00u 0 - Rule Chile 1988 1990 - Mar Sun>=9 3:00u 0 - Rule Chile 1988 1989 - Oct Sun>=9 4:00u 1:00 S Rule Chile 1990 only - Sep 16 4:00u 1:00 S Rule Chile 1991 1996 - Mar Sun>=9 3:00u 0 - Rule Chile 1991 1997 - Oct Sun>=9 4:00u 1:00 S Rule Chile 1997 only - Mar 30 3:00u 0 - Rule Chile 1998 only - Mar Sun>=9 3:00u 0 - Rule Chile 1998 only - Sep 27 4:00u 1:00 S Rule Chile 1999 only - Apr 4 3:00u 0 - Rule Chile 1999 2010 - Oct Sun>=9 4:00u 1:00 S Rule Chile 2000 2007 - Mar Sun>=9 3:00u 0 - # N.B.: the end of March 29 in Chile is March 30 in Universal time, # which is used below in specifying the transition. Rule Chile 2008 only - Mar 30 3:00u 0 - Rule Chile 2009 only - Mar Sun>=9 3:00u 0 - Rule Chile 2010 only - Apr Sun>=1 3:00u 0 - Rule Chile 2011 only - May Sun>=2 3:00u 0 - Rule Chile 2011 only - Aug Sun>=16 4:00u 1:00 S Rule Chile 2012 2014 - Apr Sun>=23 3:00u 0 - Rule Chile 2012 2014 - Sep Sun>=2 4:00u 1:00 S Rule Chile 2016 2018 - May Sun>=9 3:00u 0 - Rule Chile 2016 2018 - Aug Sun>=9 4:00u 1:00 S Rule Chile 2019 max - Apr Sun>=2 3:00u 0 - Rule Chile 2019 max - Sep Sun>=2 4:00u 1:00 S # IATA SSIM anomalies: (1992-02) says 1992-03-14; # (1996-09) says 1998-03-08. Ignore these. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Santiago -4:42:46 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - CLT 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - CLT 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 Chile CL%sT 1932 Sep 1 -4:00 - CLT 1942 Jun 1 -5:00 - CLT 1942 Aug 1 -4:00 - CLT 1946 Jul 15 -4:00 1:00 CLST 1946 Sep 1 # central Chile -4:00 - CLT 1947 Apr 1 -5:00 - CLT 1947 May 21 23:00 -4:00 Chile CL%sT ***************************************************************************************** I changed som "-" for "S" and "-03" for "CLST" and "-04" is "CLT". I compiled again and It works well. I send you this information if It is useful. Regards. Pedro Salas Diaz

2 1

Proposed Change to Maine's Time Zone *No Current Action Needed* Update
by C Yohman March 19, 2019

March 19, 2019

Public Hearings were held on March 11, 2019 on each LD. 60% and 50% public hearing testimony respectively for each LD was in opposition. TV and radio broadcasters made up the opposition. http://legislature.maine.gov/bills/display_ps.asp?snum=129&paper=HP0126PID=… http://legislature.maine.gov/bills/display_ps.asp?snum=129&paper=HP0659PID=… Works sessions are scheduled for March 20, 2019. Summary: No time zone change looks probable. Will update after the work session

1 0

tzdb under the ASIS&T microscope
by Paul Eggert March 17, 2019

March 17, 2019

tzdb was the subject of an academic study published at the most recent annual meeting of the Association for Information Science & Technology: Hauser E. UNIX time, UTC, and datetime: Jussivity, prolepsis, and incorrigibility in modern timekeeping. Proc ASIS&T. 2018;55(1):161-70. https://doi.org/10.1002/pra2.2018.14505501018 For those of us not into the lingo, "jussivity" refers to how much a word or concept commands or exhorts us, and is related to the jussive mood of verbs in some languages. For example in the Latin phrase "doceas iter" ("teach the way") in the Aeneid, the mood of "doceas" means that people ought to teach the way. "Prolepsis" refers to foreshadowing, as in a proleptic calendar that is projected backward into the past or projected into the future. "Incorrigibility" refers to the property of a belief that a person cannot give up; here, the idea is that tzdb provides its own grounds for truth and its users can't (and don't want to) correct tzdb. As you can probably tell from my having to explain the words in the title, the tz mailing list was not the intended audience of this paper. Still, it can be amusing to see how outsiders see us.

5 9

[PROPOSED] zic option for including data from a certain year onward
by Christopher Wong March 15, 2019

March 15, 2019

>From 4093e426a42421fd2d8579b07e8edb3fb116f561 Mon Sep 17 00:00:00 2001 From: Christopher Wong <christwo(a)axis.com> Date: Tue, 5 Feb 2019 15:02:57 +0100 Subject: [PATCH] zic.c: Add -k option to keep specified year and onward The -k option will take a year as input. It will strip away historical transition data before the specified year. The TZif files will be truncated. --- zic.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 69 insertions(+), 3 deletions(-) diff --git a/zic.c b/zic.c index 2ebc66a..9a3b1f5 100644 --- a/zic.c +++ b/zic.c @@ -178,6 +178,7 @@ static void mkdirs(char const *, bool); static void newabbr(const char * abbr); static zic_t oadd(zic_t t1, zic_t t2); static void outzone(const struct zone * zp, ptrdiff_t ntzones); +static zic_t ytime(zic_t year); static zic_t rpytime(const struct rule * rp, zic_t wantedy); static void rulesub(struct rule * rp, const char * loyearp, const char * hiyearp, @@ -610,6 +611,10 @@ static const char * leapsec; static const char * tzdefault; static const char * yitcommand; +/* This is used to truncate tzfiles. Only year specified by keepyear and + onward will be kept. Don't expect year to be outside range 0-9999. */ +static zic_t keepyear; + int main(int argc, char **argv) { @@ -640,7 +645,8 @@ main(int argc, char **argv) } else if (strcmp(argv[k], "--help") == 0) { usage(stdout, EXIT_SUCCESS); } - while ((c = getopt(argc, argv, "d:l:L:p:st:vy:")) != EOF && c != -1) + keepyear = ZIC_MIN; + while ((c = getopt(argc, argv, "d:k:l:L:p:st:vy:")) != EOF && c != -1) switch (c) { default: usage(stderr, EXIT_FAILURE); @@ -654,6 +660,22 @@ _("%s: More than one -d option specified\n"), return EXIT_FAILURE; } break; + case 'k': + if (keepyear == ZIC_MIN) { + keepyear = atoi(optarg); + /* Don't expect year to be outside range 0-9999. */ + if (keepyear < 0) + keepyear = 0; + if (keepyear > 9999) + keepyear = 9999; + } + else { + fprintf(stderr, +_("%s: More than one -k option specified\n"), + progname); + return EXIT_FAILURE; + } + break; case 'l': if (lcltime == NULL) lcltime = optarg; @@ -1749,7 +1771,7 @@ writezone(const char *const name, const char *const string, char version, register FILE * fp; register ptrdiff_t i, j; register int leapcnt32, leapi32; - register ptrdiff_t timecnt32, timei32; + register ptrdiff_t timecnt32, timei32, timei; register int pass; static const struct tzhead tzh0; static struct tzhead tzh; @@ -1865,6 +1887,37 @@ writezone(const char *const name, const char *const string, char version, --leapcnt32; ++leapi32; } + + timei = 0; + if (keepyear != ZIC_MIN) { + /* Discard transitions that happened before the keepyear. */ + int nbr_removes; + + nbr_removes = 0; + for (i = timei32; i < timecnt; ++i) + if (ats[i] < ytime(keepyear)) + ++nbr_removes; + timecnt32 -= nbr_removes; + timei32 += nbr_removes; + + nbr_removes = 0; + for (i = 0; i < timecnt; ++i) + if (ats[i] < ytime(keepyear)) + ++nbr_removes; + + if (nbr_removes > 0) { + /* Override the last removed transition time with the first transition + time that is the start point of the truncation range. Set defaulttype + to this first transition time. */ + --nbr_removes; + ats[nbr_removes] = ytime(keepyear); + defaulttype = types[nbr_removes]; + } + + timecnt -= nbr_removes; + timei += nbr_removes; + } + /* ** Remove old file, if any, to snap links. */ @@ -1910,7 +1963,7 @@ writezone(const char *const name, const char *const string, char version, thisleapi = leapi32; thisleapcnt = leapcnt32; } else { - thistimei = 0; + thistimei = timei; thistimecnt = timecnt; toomanytimes = thistimecnt >> 31 >> 31 >> 2 != 0; thisleapi = 0; @@ -3107,6 +3160,19 @@ tadd(zic_t t1, zic_t t2) } /* +** Given a year, compute the date (in seconds since January 1, +** 1970, 00:00). +*/ + +static zic_t +ytime(zic_t year) +{ + struct rule xr = { 0 }; + xr.r_dayofmonth = 1; + return rpytime(&xr, year); +} + +/* ** Given a rule, and a year, compute the date (in seconds since January 1, ** 1970, 00:00 LOCAL time) in that year that the rule refers to. */ -- 2.11.0 ?

4 18

[PROPOSED] Fix 'make clean' problem with clean_*.dir
by Paul Eggert March 11, 2019

March 11, 2019

* Makefile (clean_misc, clean): Use rm -fr on patterns that can match directories, so that 'make clean' works even if there is a directory check_zishrink.dir. Stick with rm -f on patterns that should match only files, for safety. --- Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 4bc72a9..25f1d35 100644 --- a/Makefile +++ b/Makefile @@ -847,11 +847,13 @@ check_zishrink_posix check_zishrink_right: \ touch $@ clean_misc: + rm -fr check_*.dir rm -f *.o *.out $(TIME_T_ALTERNATIVES) \ check_* core typecheck_* \ date tzselect version.h zdump zic yearistype libtz.a clean: clean_misc - rm -fr *.dir *.zi tzdb-*/ $(TZS_NEW) + rm -fr *.dir tzdb-*/ + rm -f *.zi $(TZS_NEW) maintainer-clean: clean @echo 'This command is intended for maintainers to use; it' -- 2.20.1

1 0

Please remove tzdata2018f
by Ankur Rana March 11, 2019

March 11, 2019

Hello Paul/Team, While doing tzdata upgrade to version 2018f, we found below issue. java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:226) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:222) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:643) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) ... 5 more We further found that the issue was addressed in version 2018g. To avoid any reoccurrence of same, would it be possible to prevent the tzdata version 2018f from downloading on iana site? [Ericsson]<http://www.ericsson.com/> ANKUR RANA Senior Software Developer Bussiness Area Digital Services - Development Unit Ericsson Block A, King Canyon "ASF Insignia" THE IT/ITES SEZ, Faridabad Road, Gawal Pahari, Gurgaon 122003, India Phone +91-124-3088600 Mobile +91-9811264594 ankur.rana(a)ericsson.com www.ericsson.com [http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign> Legal entity: Ericsson India Global Services Pvt Ltd, registered office in Gurgaon. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

8 14

Why is `Etc/UCT` not an alias of `Etc/UTC`?
by Isiah Meadows March 10, 2019

March 10, 2019

They seem to refer to the same thing, so it doesn't make much sense to me why they're considered different. I also looked in the relevant file in the source, `/etcetera`, and there doesn't seem to be any rationale for it. Was this an oversight? ----- Isiah Meadows contact(a)isiahmeadows.com www.isiahmeadows.com

11 24

Proposed Change to Maine's Time Zone *No Current Action Needed* Update
by C Yohman March 8, 2019

March 8, 2019

http://legislature.maine.gov/bills/getPDF.asp?paper=HP0659&item=1&snum=129 Text of No. 885, Rep. Baileys Proposal This one is light on substance too and impeded by: 15 United States Code, Section 260a https://www.law.cornell.edu/uscode/text/15/260a

1 0

Proposed Change to Maine's Time Zone *No Current Action Needed* Update
by C Yohman March 8, 2019

March 8, 2019

Text of No. 144, Rep. Kessler's Proposal http://legislature.maine.gov/bills/getPDF.asp?paper=HP0126&item=1&snum=129 Seems light on substance. I remain firm that this likely goes nowhere.

1 0

Proposed Change to Maine's Time Zone *No Current Action Needed*
by C Yohman March 8, 2019

March 8, 2019

Long-time lurker, first time poster. I'm putting this on the periphery, in case it comes to pass (Probability: infinitesimal). Variations come about every decade. Not that it matters in this context, but the change would make sense for the eastern half of the state with commerce ties to New Brunswick and The Maritimes. Not so much for the western half of the state where the commerce ties are strong to New Hampshire & Massachusetts. That's just a slice of the perspective. Ironically, the two measures were introduced by two southern Maine representatives. Summary: "The two bills are proposed by Democratic lawmakers and take different approaches to eliminating the time change. Rep. Chris Kessler of South Portland’s bill would move Maine into the Atlantic time zone, which would mean the state would no longer set clocks back in fall. Rep. Donna Bailey, of Saco, has proposed keeping Maine in daylight saving time all year if the federal government also does so. Florida passed a similar bill." Source: https://www.pressherald.com/2019/03/07/bills-would-say-good-night-to-daylig… (Limited access. Google Chrome -> New Incognito Window is your option for multiple free views) Further Sources: https://wgme.com/news/local/bill-would-move-maine-into-atlantic-time-zone Rep. Kessler & Rep. Bailey have been contacted for the Reference LD # or further information. Sample email sent: Representative Kessler, Citizen of Waterboro, Maine here (work in Portland, commute through a sliver of South Portland), but I read your name is attached to one of the bills. "Rep. Chris Kessler of South Portland’s bill would move Maine into the Atlantic time zone, which would mean the state would no longer set clocks back in fall." https://www.pressherald.com/2019/03/07/bills-would-say-good-night-to-daylig… I have no opinion on the matter, but if there was a change there would likely need to be a change to tzdata, the database that keeps track of timezones across the world. https://www.iana.org/time-zones Ultimately, at a basic level, it allows you to set the correct timezone on your electronic devices. What is the LD number for the measure, or where can I read the proposed text to understand the proposed change better? Regards, Chance Yohman Follow-Up: Hearing scheduled for March 11th. Will update when I know.

1 0

Arbitrary default system time?
by Arthur David Olson March 7, 2019

March 7, 2019

A question about current operating systems. They have differing ways of establishing a system-wide default local time zone at installation time. Are the current ways flexible enough to allow establishing a zone that's not in the database (for example, Freedonia Standard Time--FST--for a newly created country)? (If not, adding a zic option to help with the matter might be of use.) @dashdashado

2 1

Re: [tz] Israel DST in 1980 and 1984 ?
by Alois Treindl March 7, 2019

March 7, 2019

-------- Forwarded Message -------- Subject: Re: [tz] Israel DST in 1980 and 1984 ? Date: Wed, 6 Mar 2019 20:49:56 +0200 From: Isaac Starkman To: Alois Treindl <alois(a)astro.ch> Dear Alois, It is correct. Summer time was in that period in 1980 and 1984, see https://www.ynet.co.il/articles/0,7340,L-3951073,00.html You can of course read it in translation. I checked the local newspapers for that years. It started on midnight and end at 01.00 am Isaac On Wed, Mar 6, 2019 at 6:42 PM Alois Treindl <alois(a)astro.ch <mailto:alois@astro.ch>> wrote: Dear Isaac, can you comment on the validity of this document? Best regards Alois -------- Forwarded Message -------- Subject: [tz] Israel DST in 1980 and 1984 ? Date: Wed, 6 Mar 2019 17:40:19 +0100 From: Alois Treindl <alois(a)astro.ch> <mailto:alois@astro.ch> To: tz(a)iana.org <mailto:tz@iana.org> I have been pointed to this document http://www.moin.gov.il/Documents/%D7%A9%D7%A2%D7%95%D7%9F%20%D7%A7%D7%99%D7… whose authenticity and origin I cannot affirm, lacking Hebrew. It concerns the years 1980 and 1984, 2 August 1980 - 13 Sept 1980 5 May 1984 - 25 August 1984 and claims that DST was in force during those periods.

2 1

Israel DST in 1980 and 1984 ?
by Alois Treindl March 6, 2019

March 6, 2019

1 0

EU summer time heading for a mess
by Tony Finch March 6, 2019

March 6, 2019

Some states want to keep it. The discussions are in flux. The change might occur in 2020 or 2021. https://m.dw.com/en/european-parliament-set-to-end-eu-wide-daylight-savings… Tony. -- f.anthony.n.finch <dot(a)dotat.at> http://dotat.at

2 1

Pennsylvania State Rep seeking to end DST
by Matthew Donadio March 6, 2019

March 6, 2019

Not sure if this will go anywhere, but a Pennsylvania State Rep is seeking a co-sponsor to end DST in the state: https://www.legis.state.pa.us/cfdocs/legis/CSM/showMemoPublic.cfm?chamber=H… >From a quick read of the memo, it looks like he has done his homework on what it would actually take from beginning to end to get this done. --Matthew Donadio (matt(a)mxd120.com)

1 0

[IANA #1136519] America / Sao_Paulo in the Time Zone Database
by Amanda Baber via RT March 5, 2019

March 5, 2019

Hi, We've been asked to submit this message to the mailing list on a requester's behalf: === Contact Name: ricardotiellet Contact Email: rhiccarddo(a)hotmail.com Please, this case needs to be fixed: Wrong> America / Sao_Paulo Right> America / Brasilia If there is a need for disambiguation, just add a suffix: _DF = Federal District or Federal Capital so use: America / Brasilia_DF if there is any compatibility problem with graphical accentuation, Use Brasilia without an acute accent on the first i (í) https://en.wikipedia.org/wiki/Bras%C3%ADlia https://en.wikipedia.org/wiki/Brasilia Please contact me if you need. Thanks a lot. === He indicated to us that he may not check the mailing list for replies. Best regards, Amanda Baber Lead IANA Services Specialist

4 4

tzdb timezone names/identifiers and links (was: Add new timezone for Hanoi Capital, Vietnam)
by Hans-Joerg Happel March 1, 2019

March 1, 2019

Dear all, as a follow-up to the "Hanoi" thread, I've some questions regarding tzdb policies. As it is a slightly separate / more general point, I'll single that thread out from the initial "Hanoi" discussion. In particular, I'd like to understand the background of the following item (taken from https://data.iana.org/time-zones/theory.html#naming) >There should typically be at least one name for each ISO 3166-1 <https://en.wikipedia.org/wiki/ISO_3166-1> officially >assigned two-letter code for an inhabited country or territory. I initially thought this would be the reason for the "Links" of "Asia/Phnom_Penh" and "Asia/Vientiane" to "Asia/Bangkok". However, latest discussion in the "Hanoi" thread rather attributed these two aliases to backwards compatibility after prior data was moved to the backzone file. I'd assume the quoted "ISO 3166-1"-based policy could make sense for two reasons: a) Congruence of ids and decision-making bodies (i.e., countries/governments): In contrast to data stored using "Asia/Bangkok", systems/data using the "Asia/Phnom_Penh" name/link/alias/id would not need to change/re-configure in case the government of Cambodia decides to deviate from "Asia/Bangkok" at some time b) Politically: Even if tzdb names might not be intended as "names", they do surface from time to time, as with configuring time zones on a machine [1], or by applications just passing through tzdb names. I can somehow understand that this is not fully satisfactory in the Vietnam/Hanoi case right now (see below). While it is neither the intention nor the concern of tzdb to deal with this, one can argue that in practice, there is still clearly a practical impact of tzdb names/ids. So any information on the rationale for the above-quoted rule is appreciated. Also, I see there are recommendations for implementers regarding localization (e.g., reference to Unicode CLDR), but I could not find recommendations concerning the usage of tzdb names/ids/links/aliases - which, in my understanding, will be the String persisted by most applications in the end? If so, setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb identifier would, to some degree, effectively tie that data to Thai legislation. In case Vietnam would deviate from "Asia/Bangkok" in the future (by either Thai or Vietnamese decision), legacy data might need to be change to an "Asia/Hanoi" identifier. I'd be interested in pointers if this aspect was ever discussed here or is considered relevant at all. Thanks and best, Hans-Joerg ps.: as for the Vietnam case, note that the "displayName()" property in Java shows "Indochina" for most zones under discussion [2] Also Unicode CLDR translations look tricky in this case (http://st.unicode.org/cldr-apps/survey?_=en&x=r_zones) [1] E.g. https://askubuntu.com/questions/323131/setting-timezone-from-terminal/323163 points out the two options of |sudo cp /usr/share/zoneinfo/Asia/Bangkok /etc/localtime| (explicit!) or |tzselect | ..yielding the following dialogue: Please select a country whose clocks agree with yours. 1) Afghanistan 18) Israel 35) Palestine ......... 15) Indonesia 32) Nepal 49) Vietnam 16) Iran 33) Oman 50) Yemen 17) Iraq 34) Pakistan #? 49 Please select one of the following time zone regions. 1) Indochina (most areas) 2) Vietnam (south) ...which looks better, but is also not ideal from a user point-of-view... [2] Java TimeZone.getDisplayName() output for EN/DE/FR locale (Oracle JDK 1.8.0_191): Asia/Bangkok / Indochina Time Asia/Bangkok / Indochina Zeit Asia/Bangkok / Heure d'Indochine Asia/Ho_Chi_Minh / Indochina Time Asia/Ho_Chi_Minh / Indochina Zeit Asia/Ho_Chi_Minh / Heure d'Indochine Asia/Phnom_Penh / Indochina Time Asia/Phnom_Penh / Indochina Zeit Asia/Phnom_Penh / Heure d'Indochine Asia/Saigon / Indochina Time Asia/Saigon / Indochina Zeit Asia/Saigon / Heure d'Indochine Asia/Vientiane / Indochina Time Asia/Vientiane / Indochina Zeit Asia/Vientiane / Heure d'Indochine VST / Indochina Time VST / Indochina Zeit VST / Heure d'Indochine -- audriga GmbH Durlacher Allee 47 76131 Karlsruhe, Germany Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179 www.twitter.com/audriga <http://www.twitter.com/audriga> www.audriga.com <http://www.audriga.com/> Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142

22 105