- tz - lists.iana.org

[PROPOSED 1/2] Rename ‘lint’ to ‘GCC_LINT’
by Paul Eggert May 18, 2017

May 18, 2017

* Makefile (GCC_DEBUG_FLAGS): * private.h (INITIALIZE): Rename ‘lint’ to ‘GCC_LINT’, as the macro is intended for GCC, not for traditional ‘lint’. --- Makefile | 2 +- private.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index e7c6ac0..bcfdcb2 100644 --- a/Makefile +++ b/Makefile @@ -159,7 +159,7 @@ LDLIBS= # (or some other number) to set the maximum time zone abbreviation length # that zic will accept without a warning (the default is 6) # $(GCC_DEBUG_FLAGS) if you are using recent GCC and want lots of checking -GCC_DEBUG_FLAGS = -Dlint -g3 -O3 -fno-common -fstrict-aliasing \ +GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common -fstrict-aliasing \ -Wall -Wextra \ -Wbad-function-cast -Wcast-align -Wdate-time \ -Wdeclaration-after-statement \ diff --git a/private.h b/private.h index e9eb211..6886185 100644 --- a/private.h +++ b/private.h @@ -566,7 +566,7 @@ static time_t const time_t_max = MAXVAL(time_t, TYPE_BIT(time_t)); ** INITIALIZE(x) */ -#ifdef lint +#ifdef GCC_LINT # define INITIALIZE(x) ((x) = 0) #else # define INITIALIZE(x) -- 2.9.4

1 1

Morocco changes May 27th 2017 instead of May 21th
by Info - avisched.com May 17, 2017

May 17, 2017

Morocco is about to switch on May 27th back to UTC from +1. The current release doesn't reflect that (May 21st). Is there any update planned before the actual transition? Many thanks! Martin

5 5

Asia/Harbin, Asia/Chongqing and Asia/Kashgar
by Phake Nick May 13, 2017

May 13, 2017

iirc, according to past conversation on the mailing list, the reason why these timezones that are not in use for many years already still exists in tz database is because of legacy reason, however given that Asia/Ishigaki were deleted from this database in 1999 when it's found to be not in use, is there any reason preventing the same to be done to Asia/Harbin, Asia/Chongqing, and Asia/Kashgar?

2 1

gcc 8 demanded patch (from NetBSD)
by Robert Elz May 11, 2017

May 11, 2017

The following patch was recently added to NetBSD, to appease GCC 8 (apparently) ... "hit" is a bool, and it seems gcc 8 does not like ++ operators applied to one of those. (deleted parts of the diff which just showed the version ID string being updated...) kre Index: src/lib/libc/time/localtime.c diff -u src/lib/libc/time/localtime.c:1.106 src/lib/libc/time/localtime.c:1.107 --- src/lib/libc/time/localtime.c:1.106 Sat Mar 11 18:23:14 2017 +++ src/lib/libc/time/localtime.c Tue May 9 02:30:49 2017 @@ -1716,7 +1716,7 @@ timesub(const time_t *timep, int_fast32_ sp->lsis[i - 1].ls_trans + 1 && sp->lsis[i].ls_corr == sp->lsis[i - 1].ls_corr + 1) { - ++hit; + hit = true; --i; } }

8 13

TZDEFRULESTRING is increasingly out-of-date
by Tom Lane May 7, 2017

May 7, 2017

Due to a script's unintended failure to supply a -p option to zic, I recently had my nose rubbed in the fact that localtime.c still has this as the fallback when the "posixrules" link can't be loaded: /* ** The DST rules to use if TZ has no rules and we can't load TZDEFRULES. ** We default to US rules as of 1999-08-17. ** POSIX 1003.1 section 8.1.1 says that the default DST rules are ** implementation dependent; for historical reasons, US rules are a ** common default. */ #ifndef TZDEFRULESTRING #define TZDEFRULESTRING ",M4.1.0,M10.5.0" #endif /* !defined TZDEFDST */ It's now over ten years since the US last followed those rules; isn't it time to update TZDEFRULESTRING to match current law? I can't really think of any situation where the current default would be of any value now. Apologies if this policy is being followed intentionally; but I couldn't find any discussion of the point by googling. regards, tom lane

2 1

Potted history of timekeeping from the BBC
by John Haxby April 21, 2017

April 21, 2017

This is from a series of things that made the modern economy, it says on the web page: Tick tock: The importance of knowing the right time: http://www.bbc.co.uk/news/business-39129620 In one short page it manages to mention everything but DST :) and it includes a picture of Harrison No 1. (If you're ever near Greenwich I recommend visiting the Royal Observatory, taking the obligatory foot-in-both-hemispheres selfie and then going to look at the clocks.) >From the BBC web page though, I particularly noticed this: > Some financiers recently calculated it was worth spending $300m (£247m) drilling through mountains between Chicago and New York to lay fibre-optic cables in a slightly straighter line. That sped up communication between the two cities' exchanges by three milliseconds. jch

10 10

Re: [tz] leapseconds.awk, LEAP directives and references
by Chris Woodbury April 21, 2017

April 21, 2017

In the course of reviewing the AWK script leapseconds.awk, I was disturbed by the fact that it (1) operated on the comments (probably not a good idea) in the NIST produced leap-seconds.list file rather than the NTP timestamp itself and (2) that it assumed that leap seconds would only occur in December and June. The regulation that governs leap seconds, ITU-R TF.460-6 <https://www.itu.int/rec/R-REC-TF.460-6-200202-I/>, actually allows leap seconds to occur at the end of any UTC month. Annex 1, Section 2: Leap Seconds 2.1 A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September. I note, in the event of a (highly unlikely) negative leap second, the LEAP directive generated is for 23:59:59 which, in the case of a negative leap second, doesn't exist. I reviewed the C code and, it seems to me, the transaction added should actually be for the second before, 23:59:58, as the transaction itself causes 23:59:59 to be skippedaltogether. (Kinda hard to skip an event if you're in it.) I bring this up as I've alrady written the changes necessary but I want to verify the correctness of this last beforesubmitting them. Also, I've an AWK script that uses the IERS file Leap_Seconds.dat rather than the NIST leap-seconds.listfile. Leap_Seconds.dat is a straight list of leap-seconds. USNO MAIA also has straight list of leap-seconds in a different format. See URLs: <http://hpiers.obspm.fr/iers/bul/bulc/Leap_Seconds.dat> <http://maia.usno.navy.mil/ser7/leapsec.dat> Either of these would, particularly the IERS file as it has few but excellent comments, be a better source of leap-second information than the once removed NIST file leap-seconds.list; which is purposed for another task. Lastly, thanks to Dr. Eggert for including the reference I gave him to the AAPT Resource Letter that included Terry Quinn's article in the NIST Time and Frequency Division's PDF archive (1168). Anyone wanting to know about Time and Frequency Measurement might want to read the other articles as well as Dr. Quinn's. Another good, comprehensive article is "The leap second: its history and possible future" by R.A. Nelson, et al, from Metrogia Vol 38, pp. 509-529 (2001). PDF available (with permission) at: <https://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf>

9 16

[PROPOSED] Use railway time for India from 1870-1941
by Paul Eggert April 20, 2017

April 20, 2017

From: Paul Eggert <eggert(a)Penguin.CS.UCLA.EDU> * NEWS: Document this. * asia (Asia/Yangon): Add 7 s to times from 1880 to 1920. (Asia/Kolkata): Switch from HMT to MMT in 1870, and from MMT to IST in 1906. --- NEWS | 11 +++++++++++ asia | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 64 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index f986cf6..ad099f4 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,16 @@ News for the tz database +Unreleased, experimental changes + + Changes to past time stamps + + Use railway time for Asia/Kolkata before 1941, by switching to + Madras local time (UT +052110) in 1870, then to IST (UT +0530) in + 1906. Also, treat 1941-2's +0630 as DST, like 1942-5. + + Add 7 s to the UT offset in Asia/Yangon before 1920. + + Release 2017b - 2017-03-17 07:30:38 -0700 Briefly: Haiti has resumed DST. diff --git a/asia b/asia index 35774c6..f027071 100644 --- a/asia +++ b/asia @@ -258,9 +258,15 @@ Zone Asia/Brunei 7:39:40 - LMT 1926 Mar # Bandar Seri Begawan # Milne says 6:24:40 was the meridian of the time ball observatory at Rangoon. +# From Paul Eggert (2017-04-20): +# Page 27 of Reed & Low (cited for Asia/Kolkata) says "Rangoon local time is +# used upon the railways and telegraphs of Burma, and is 6h. 24m. 47s. ahead +# of Greenwich." This refers to the period before Burma's transition to +0630, +# a transition for which Shanks is the only source. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Yangon 6:24:40 - LMT 1880 # or Rangoon - 6:24:40 - RMT 1920 # Rangoon Mean Time? +Zone Asia/Yangon 6:24:47 - LMT 1880 # or Rangoon + 6:24:47 - RMT 1920 # Rangoon local time 6:30 - +0630 1942 May 9:00 - +09 1945 May 3 6:30 - +0630 @@ -887,14 +893,55 @@ Zone Asia/Dili 8:22:20 - LMT 1912 Jan 1 # local time in favor of Indian Standard Time.... Journalists called this # dispute the "Battle of the Clocks." It lasted nearly half a century. +# From Paul Eggert (2017-04-20): +# Good luck trying to nail down old timekeeping records in India. +# "... in the nineteenth century ... Madras Observatory took its magnetic +# measurements in Göttingen time, its meterological measurements on Madras +# (local) time, dropped its time ball on Greenwich (ocean navigator's) time, +# and distributed civil (local time)." -- Bartky IR. Selling the time: +# 19th-century timekeeping in america. Stanford U Press (2000), 247 note 19. +# "A more potent cause of resistance to the general adoption of the present +# standard time lies in the fact that it is Madras time. The citizen of +# Bombay, proud of being 'primus in Indis' and of Calcutta, equally proud of +# his city being the Capital of India, and - for a part of the year - the Seat +# of the Supreme Government, alike look down on Madras, and refuse to change +# the time they are using, for that of what they regard as a benighted +# Presidency; while Madras, having for long given the standard time to the +# rest of India, would resist the adoption of any other Indian standard in its +# place." -- Oldham RD. On Time in India: a suggestion for its improvement. +# Proceedings of the Asiatic Society of Bengal (April 1899), 49-55. +# +# "In 1870 ... Madras time - 'now used by the telegraph and regulated from the +# only government observatory' - was suggested as a standard railway time, +# first to be dopted on the Great Indian Peninsular Railway (GIPR).... +# Calcutta, Bombay, and Karachi, were to be allowed to continue with their +# local time for civil purposes." - Prasad R. Tracks of Change: Railways and +# Everyday Life in Colonial India. Cambridge University Press (2016), 145. +# +# Reed S, Low F. The Indian Year Book 1936-37. Bennett, Coleman, pp 27-8. +# https://archive.org/details/in.ernet.dli.2015.282212 +# This lists +052110 as Madras local time used in railways, and says that on +# 1906-01-01 railways and telegraphs in India switched to +0530. Some +# municipalities retained their former time, and the time in Calcutta +# continued to depend on whether you were at the railway station or at +# government offices. Government time was at +055320 (according to Shanks) or +# at +0554 (according to the Indian Year Book). Railway time is more +# appropriate for our purposes, as it was better documented, it is what we do +# elsewhere (e.g., Europe/London before 1880), and after 1906 it was +# consistent in the region now identified by Asia/Kolkata. So, use railway +# time for 1870-1941. Shanks is our only (and dubious) source for the +# 1941-1945 data. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Asia/Kolkata 5:53:28 - LMT 1880 # Kolkata - 5:53:20 - HMT 1941 Oct # Howrah Mean Time? - 6:30 - +0630 1942 May 15 +Zone Asia/Kolkata 5:53:28 - LMT 1854 Jun 28 # Kolkata + 5:53:20 - HMT 1870 # Howrah Mean Time? + 5:21:10 - MMT 1906 Jan 1 # Madras local time + 5:30 - IST 1941 Oct + 5:30 1:00 +0630 1942 May 15 5:30 - IST 1942 Sep 5:30 1:00 +0630 1945 Oct 15 5:30 - IST -# The following are like Asia/Kolkata: +# Since 1970 the following are like Asia/Kolkata: # Andaman Is # Lakshadweep (Laccadive, Minicoy and Amindivi Is) # Nicobar Is -- 2.9.3

1 0

Mouradconstantine@icloud.com
by Mourad Constantine April 13, 2017

April 13, 2017

Sent from my iPhone

1 0

Urumqi timezone.
by gfb hjjhjh April 13, 2017

April 13, 2017

As there are two different timmezones being used in Xinjiang, China, would it be a good idea to create another timezone named something like Asia/Urumqi2 to correspond to the different timezone being used in the area?

9 13

Fwd: [IANA #939704] Contributions to this list
by Erast Fandorin April 8, 2017

April 8, 2017

Dear Sir/Madam Please make the changes to time zone database: Ukraine: Kiev => Kyiv, Zaporozh'ye => Zaporizhia, Uzhgorod => Uzhhorod, Odessa => Odesa according to legal names and MORE COMMON USE in ENGLISH (like booking services or names of the airports, railway stations, river and sea ports and everyday speaking usage). Autonomous Republic of Crimea (Ukraine): Crimea, Republic of => Crimea, Autonomous Republic of according to legal name of the Ukrainian territory occupied by Russians terrorists forces. The name "Autonomous Republic of Crimea" is officially recognized by all of the countries (except the Russian Federation - the terrorist's country number one in the World) and in international COMMON USE in ENGLISH navigation systems of the air, sea and river transport systems. Sevastopol MSK => Sevastopol KMT Simferopol MSK => Simferopol KMT according to legal time usage on the Ukrainian territory -------- Forwarded Message -------- Тема: [IANA #939704] Contributions to this list Дата: Thu, 01 Dec 2016 20:16:50 +0000 Від: Amanda Baber via RT <iana-questions(a)iana.org> <iana-questions(a)iana.org> Відповісти: iana-questions(a)iana.org Кому: aristonomy(a)gmail.com Dear Sir/Madam, Thank you for contacting us. We host the Time Zone Database, but updates are made by the Time Zone Coordinator in consultation with the Time Zone mailing list, in accordance with RFC 6557. Questions about the contents of the database should be sent to the mailing list. For mailing list archives and subscription information, please see http://www.iana.org/time-zones Best regards, Amanda Baber Lead IANA Services Specialist PTI On Thu Dec 01 10:28:43 2016, aristonomy(a)gmail.com wrote: > To the holder of iana.org! > > Contributions to this list of time zones! > > "Uzhhorod International Airport", "Kyiv International Airport > (Zhuliany)", "Kyiv Boryspil international airport", "Zaporizhia > International Airport" which are MORE COMMON USE in every ENGLISH > booking service. The same names are used in the railway stations names > and booking services. > > Even more! Kyiv, Uzhhorod, Zaporizhia, Odesa are the international names > of the cityes, river and sea ports, airports and railway stations, parts > of the administration and state organizations names and etcetera. > > The only common use of the names: Kiev, Zaporozh'ye, Uzhgorod and Odessa > were in USSR - the country which is not exist any more (thanks to God!), > and in the country which are occupied the part of Ukraine. Supporting > such spelling is a direct support of the country which is now are the N1 > Country Terrorist of the World!! > > Europe/Simferopol and Europe/Sevastopol now are under Russian occupation > and NO legal international communications for hole Autonomous Republic > of Crimea (Ukraine) and this territory are legally under Ukrainians Law! > > Supporting of the time change to the MSK time zone is a direct support > of occupation!! > > This letter are public and will be shared to social network. > > Stop support of Russian invasion to Ukraine and Georgia!! Stop support > of the biggest terrorists organization which Russian Federation are! > > > # From Tim Parenti (2014-07-03): > > # Europe/Simferopol covers... > > # ** **** Crimea, Republic of > > # ** **** Sevastopol > > > > Zone Europe/Simferopol 2:16:24 - LMT 1880 > > 2:16 - SMT 1924 May 2 # Simferopol Mean T > > 2:00 - EET 1930 Jun 21 > > 3:00 - MSK 1941 Nov > > 1:00 C-Eur CE%sT 1944 Apr 13 > > 3:00 Russia MSK/MSD 1990 > > 3:00 - MSK 1990 Jul 1 2:00 > > 2:00 - EET 1992 > > # Central Crimea used Moscow time 1994/1997. > > # > > # From Paul Eggert (2006-03-22): > > # The _Economist_ (1994-05-28, p 45) reports that central Crimea switched > > # from Kiev to Moscow time sometime after the January 1994 elections. > > # Shanks (1999) says "date of change uncertain", but implies that it > > happened > > # sometime between the 1994 DST switches. Shanks & Pottenger simply say > > # 1994-09-25 03:00, but that can't be right. For now, guess it > > # 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 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. > > 3:00 Russia MSK/MSD 1997 > > 3:00 - MSK 1997 Mar lastSun 1:00u > > # From Alexander Krivenyshev (2014-03-17): > > # time change at 2:00 (2am) on March 30, 2014 > > # http://vz.ru/news/2014/3/17/677464.html > > # From Paul Eggert (2014-03-30): > > # Simferopol and Sevastopol reportedly changed their central town clocks > > # late the previous day, but this appears to have been ceremonial > > # and the discrepancies are small enough to not worry about. > > 2:00 EU EE%sT 2014 Mar 30 2:00 > > 4:00 - MSK 2014 Oct 26 2:00s > > 3:00 - MSK > > > > > > > > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > > # Most of Ukraine since 1970 has been like Kiev. > > # "Kyiv" is the transliteration of the Ukrainian name, but > > # "Kiev" is more common in English. > > Zone Europe/Kiev 2:02:04 - LMT 1880 > > 2:02:04 - KMT 1924 May 2 # Kiev Mean Time > > > > # "Uzhhorod" is the transliteration of the Rusyn/Ukrainian > > pronunciation, but > > # "Uzhgorod" is more common in English. > > Zone Europe/Uzhgorod 1:29:12 - LMT 1890 Oct > > > > # Zaporozh'ye and eastern Lugansk oblasts observed DST 1990/1991. > > # "Zaporizhia" is the transliteration of the Ukrainian name, but > > # "Zaporozh'ye" is more common in English. Use the common English > > # spelling, except omit the apostrophe as it is not allowed in > > # portable Posix file names. > > Zone Europe/Zaporozhye 2:20:40 - LMT 1880 >

2 1

MS-Windows 10 and New Zealand yesterday
by Paul Eggert April 3, 2017

April 3, 2017

Chris Keall of the National Business Review (New Zealand) reports that laptops and phones running Microsoft Windows 10 missed the end of daylight saving time in New Zealand yesterday. Microsoft Windows 7 laptops operated correctly. This leads me to think that the problem has something to do with the tz database, as MS-Windows 7 does not use tzdata whereas MS-Windows 8.1 and later use tzdata, at least in some cases. Does anyone have technical information about why the glitch happened? Is there some way we can help avoid it in the future? Keall C. Living in the past: Windows 10 fails to update for end of daylight saving. NBR 2017-04-03. https://www.nbr.co.nz/article/living-past-windows-10-fails-update-end-dayli…

3 2

zone.tab / zone1970.tab inconsistency for TF/UM/VN
by Neil Fuller April 3, 2017

April 3, 2017

This may be a misunderstanding on my part about the file formats of zone.tab and zone1970.tab and how consistent they are expected to be. I expect the exact zone IDs to be different, but there are only a few cases where countries differ in the number of referenced zone IDs. I realize that zone.tab is intended for backward compatibility but it looks like it is being well maintained. Is this difference expected? If it is, can somebody explain? Details below the line. Thanks for all the hard work. Neil. ------------------- 2017b: TF zone.tab: TF -492110+0701303 Indian/Kerguelen zone1970.tab: RE,TF -2052+05528 Indian/Reunion Réunion, Crozet, Scattered Islands TF -492110+0701303 Indian/Kerguelen Kerguelen, St Paul Island, Amsterdam Island ------------------ UM zone.tab: UM +2813-17722 Pacific/Midway Midway Islands UM +1917+16637 Pacific/Wake Wake Island zone1970.tab: AS,UM -1416-17042 Pacific/Pago_Pago Samoa, Midway UM +1917+16637 Pacific/Wake Wake Island US,UM +211825-1575130 Pacific/Honolulu Hawaii ------------------ VN zone.tab: VN +1045+10640 Asia/Ho_Chi_Minh zone1970.tab: TH,KH,LA,VN +1345+10031 Asia/Bangkok Indochina (most areas) VN +1045+10640 Asia/Ho_Chi_Minh Vietnam (south) -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902

2 2

[PATCH] Give free source for Quinn paper
by Paul Eggert April 2, 2017

April 2, 2017

* leapseconds.awk, zic.8: Mention the NIST-distributed copy of the Quinn paper, too. --- leapseconds.awk | 5 ++++- zic.8 | 5 ++++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/leapseconds.awk b/leapseconds.awk index 21fe540..8cd2f7e 100644 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -20,7 +20,10 @@ BEGIN { print "# periodically uses leap seconds to keep UTC to within 0.9 s of UT1" print "# (which measures the true angular orientation of the earth in space); see" print "# Terry J Quinn, The BIPM and the accurate measure of time," - print "# Proc IEEE 79, 7 (July 1991), 894-905 <http://dx.doi.org/10.1109/5.84965>." + print "# Proc IEEE 79, 7 (July 1991), 894-905 <http://dx.doi.org/10.1109/5.84965>," + print "# reprinted in: Hackman C, Sullivan DB (eds), Time and frequency measurement," + print "# American Association of Physics Teachers (1996)," + print "# <http://tf.nist.gov/general/pdf/1168.pdf>, 75-86." print "# There were no leap seconds before 1972, because the official mechanism" print "# accounting for the discrepancy between atomic time and the earth's rotation" print "# did not exist until the early 1970s." diff --git a/zic.8 b/zic.8 index e5e71f5..25dac78 100644 --- a/zic.8 +++ b/zic.8 @@ -463,7 +463,10 @@ if a second was skipped. .\" than one leap second to be inserted or deleted at a time. .\" The C Standard is in error in suggesting the possibility. .\" See Terry J Quinn, The BIPM and the accurate measure of time, -.\" Proc IEEE 79, 7 (July 1991), 894-905. +.\" Proc IEEE 79, 7 (July 1991), 894-905, reprinted in +.\" Hackman C, Sullivan DB (eds), Time and frequency measurement, +.\" American Association of Physics Teachers (1996), +.\" <http://tf.nist.gov/general/pdf/1168.pdf>, 75-86." .\" or .\" .q ++ .\" if two seconds were added -- 2.9.3

1 0

Re: [tz] Israel Timezone query
by Vidyalakshmi Badiger March 29, 2017

March 29, 2017

Dear Tz Team, As per the below request the Time zone value for Israel need to be changed from “GMT +2 (Default Value) to (Default value). So how can we proceed to provide this change? Regards, Vidya From: 황주연 [mailto:juyeon.hwang@lge.com] Sent: Tuesday, March 28, 2017 5:16 AM To: Vidyalakshmi Badiger/LGSIA MPS-7(vidya.badiger(a)lge.com) Cc: 김성경/책임연구원/MC연구소 SW플랫폼실 1팀 1파트(sungkyoung.kim(a)lge.com); Divya Srivastava/LGSIA MPS-7(divya.srivastava(a)lge.com); 황주연/선임연구원/MC연구소 SW플랫폼실 1팀 2파트(juyeon.hwang(a)lge.com) Subject: RE: Israel Timezone query Dear Vidyalakshmi Badiger, We not modify tzdata manually. I think you can contact IANA (tz(a)iana.org<mailto:tz@iana.org>) Thank you. From: Vidyalakshmi Badiger [mailto:vidya.badiger@lge.com] Sent: Monday, March 27, 2017 6:51 PM To: juyeon.hwang(a)lge.com<mailto:juyeon.hwang@lge.com> Cc: sungkyoung.kim(a)lge.com<mailto:sungkyoung.kim@lge.com>; Divya Srivastava <divya.srivastava(a)lge.com<mailto:divya.srivastava@lge.com>> Subject: FW: Israel Timezone query Dear Juyeon, As per the below request the Time zone value for Israel need to be changed from “GMT +2 (Default Value) to (Default value). So how can we proceed to provide this change? Regards, Vidya From: Vidyalakshmi Badiger/LGSIA MPS-7(vidya.badiger(a)lge.com<mailto:vidya.badiger@lge.com>) Sent: Thursday, March 23, 2017 6:27 PM To: Raghavendra Revankar/LGSIA MPS-7(raghavendra.revankar(a)lge.com<mailto:raghavendra.revankar@lge.com>); Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>); Satish K R/LGSIA MPS-7(satish.babu(a)lge.com<mailto:satish.babu@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>) Subject: RE: Israel Timezone query Dear Veena, Please find the details, Can you please confirm the current time zone value present in Google’s library for Israel all buyers? ---- GMT+02:00 Israel Standard Time [Jerusalem] what action need to be taken if the Google’s value is not matching with the above new GPRI change. ----- Need to check with HQ ,as we need to change time zone by modifying metaZones.txt Regards, Vidya From: Raghavendra Revankar/LGSIA MPS-7(raghavendra.revankar(a)lge.com<mailto:raghavendra.revankar@lge.com>) Sent: Thursday, March 23, 2017 5:56 PM To: Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>); Satish K R/LGSIA MPS-7(satish.babu(a)lge.com<mailto:satish.babu@lge.com>); Vidyalakshmi Badiger/LGSIA MPS-7(vidya.badiger(a)lge.com<mailto:vidya.badiger@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Nagappa Karajol/LGSIA MPS-7(nagappa.karajol(a)lge.com<mailto:nagappa.karajol@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>); Harshith C K/LGSIA MPS-7(harshith.ck(a)lge.com<mailto:harshith.ck@lge.com>) Subject: RE: Israel Timezone query ++ VIDYA From: Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>) Sent: Thursday, 23 March 2017 5:54 PM To: Satish K R/LGSIA MPS-7(satish.babu(a)lge.com<mailto:satish.babu@lge.com>); Raghavendra Revankar/LGSIA MPS-7(raghavendra.revankar(a)lge.com<mailto:raghavendra.revankar@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Nagappa Karajol/LGSIA MPS-7(nagappa.karajol(a)lge.com<mailto:nagappa.karajol@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>); Harshith C K/LGSIA MPS-7(harshith.ck(a)lge.com<mailto:harshith.ck@lge.com>) Subject: RE: Israel Timezone query ++ Raghavendra From: Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>) Sent: Thursday, March 23, 2017 10:01 AM To: Satish K R/LGSIA MPS-7(satish.babu(a)lge.com<mailto:satish.babu@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Nagappa Karajol/LGSIA MPS-7(nagappa.karajol(a)lge.com<mailto:nagappa.karajol@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>); Harshith C K/LGSIA MPS-7(harshith.ck(a)lge.com<mailto:harshith.ck@lge.com>) Subject: RE: Israel Timezone query Dear Satish, As requested in below mail, please let us know the Google’s IANA DB version used for all models for Timezone check. Regards, Veena. From: Harshith C K/LGSIA MPS-7(harshith.ck(a)lge.com<mailto:harshith.ck@lge.com>) Sent: Thursday, March 23, 2017 9:56 AM To: Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Nagappa Karajol/LGSIA MPS-7(nagappa.karajol(a)lge.com<mailto:nagappa.karajol@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>) Subject: RE: Israel Timezone query Dear Veena, As you mentioned, timezone is picked from IANA database shared by Google which is part of frameworks. Please check with CFW team for DB version details. Thanks & Regards, Harshith From: Veena Kalasannavar/LGSIA DP PL(veena.kalasannavar(a)lge.com<mailto:veena.kalasannavar@lge.com>) Sent: Thursday, March 23, 2017 9:41 AM To: Harshith C K/LGSIA MPS-7(harshith.ck(a)lge.com<mailto:harshith.ck@lge.com>) Cc: Harish Mollin/LGSIA DP PL(harish.mollin(a)lge.com<mailto:harish.mollin@lge.com>); Nagappa Karajol/LGSIA MPS-7(nagappa.karajol(a)lge.com<mailto:nagappa.karajol@lge.com>); Bhavya SP/LGSIA DP PL(bhavya.sp(a)lge.com<mailto:bhavya.sp@lge.com>) Subject: Israel Timezone query Dear Harshit, Recently we observed that Israel FTE has updated timezone for Partner buyer. Please refer below screenshot. [cid:image001.png@01D2A7AB.923BBB40] But as we are aware, time zone is no more referred from GPRI and Google’s library is used to for the same. Can you please confirm the current time zone value present in Google’s library for Israel all buyers? Also please let us know, what action need to be taken if the Google’s value is not matching with the above new GPRI change. Regards, Veena.

5 4

[PATCH] Fix some word repetitions
by Paul Eggert March 25, 2017

March 25, 2017

* Makefile, europe, localtime.c, tz-art.htm, tzfile.5: Fix repeated instances of words in commentary. (Problem with 'Makefile'reported by Curtis Manwaring.) --- Makefile | 2 +- europe | 2 +- localtime.c | 2 +- tz-art.htm | 2 +- tzfile.5 | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 8067ba0..87fcfab 100644 --- a/Makefile +++ b/Makefile @@ -75,7 +75,7 @@ LIBDIR= $(TOPDIR)/lib # If you want only POSIX time, with time values interpreted as # seconds since the epoch (not counting leap seconds), use # REDO= posix_only -# below. If you want want only "right" time, with values interpreted +# below. If you want only "right" time, with values interpreted # as seconds since the epoch (counting leap seconds), use # REDO= right_only # below. If you want both sets of data available, with leap seconds not diff --git a/europe b/europe index 558b9f1..088d0a8 100644 --- a/europe +++ b/europe @@ -1524,7 +1524,7 @@ Zone Atlantic/Reykjavik -1:28 - LMT 1908 # From Paul Eggert (2016-10-27): # Go with INRiM for DST rules, except as corrected by Inglis for 1944 # for the Kingdom of Italy. This is consistent with Renzo Baldini. -# Model Rome's occupation by using using C-Eur rules from 1943-09-10 +# Model Rome's occupation by using C-Eur rules from 1943-09-10 # to 1944-06-04; although Rome was an open city during this period, it # was effectively controlled by Germany. # diff --git a/localtime.c b/localtime.c index afc7438..4bedb5c 100644 --- a/localtime.c +++ b/localtime.c @@ -639,7 +639,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, } } /* - ** If type 0 is is unused in transitions, + ** If type 0 is unused in transitions, ** it's the type to use for early times. */ for (i = 0; i < sp->timecnt; ++i) diff --git a/tz-art.htm b/tz-art.htm index f726cce..17b8719 100644 --- a/tz-art.htm +++ b/tz-art.htm @@ -24,7 +24,7 @@ into problems that programmers have with timekeeping.</li> Explaining The Mysteries Of Time Zones</a>" (2017; 2:15) briefly says why France has more time zones than Russia.</a> <li> -"About Time" (1962; 53 minutes) is part of the the +"About Time" (1962; 53 minutes) is part of the Bell Science extravaganza, with Frank Baxter, Richard Deacon, and Les Tremayne. Its advisor was Richard Feynman, and it was voiced by Mel Blanc. (<a href="http://www.imdb.com/title/tt0154110/">IMDb entry</a>.)</li> diff --git a/tzfile.5 b/tzfile.5 index 0c907bc..2e88763 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -145,7 +145,7 @@ POSIX-TZ-environment-variable-style string for use in handling instants after the last transition time stored in the file (with nothing between the newlines if there is no POSIX representation for such instants). -The POSIX-style string must must agree with the local time type after +The POSIX-style string must agree with the local time type after both data's last transition times; for example, given the string .q "WET0WEST,M3.5.0,M10.5.0/3" then if a last transition time is in July, the transition's local time -- 2.9.3

1 0

[tz-announce] 2017b release of tz code and data available
by Paul Eggert March 23, 2017

March 23, 2017

The 2017b 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: Haiti has resumed DST. Changes to past and future time stamps Haiti resumed observance of DST in 2017. (Thanks to Steffen Thorsen.) Changes to past time stamps Liberia changed from -004430 to +00 on 1972-01-07, not 1972-05-01. Use "MMT" to abbreviate Liberia's time zone before 1972, as "-004430" is one byte over the POSIX limit. (Problem reported by Derick Rethans.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2017b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2017b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2017b.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 f8ebe3a644e12b294dfc3c06c5243c1b9c13a7e8 dated 2017-03-17 07:30:38 -0700 and tagged '2017b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 9a73af4b868506d1f6287a8285dea489e68f6828da19509114f9144e2a2019c7fd28f4fb98ea907030d11d011ce3a87d99dbe43bca218beddafff151f0d61df1 tzcode2017b.tar.gz 3e090dba1f52e4c63b4930b28f4bf38b56aabd6728f23094cb5801d10f4e464f17231f17b75b8866714bf98199c166ea840de0787b75b2274aa419a4e14bbc4d tzdata2017b.tar.gz 5003caab927eccf1d8f13391f4658733b3cfa05be1fcc99e0ab127ef6673514239d906677ab9b64f51777d450262d1db1868647b6afa868ab0ef93dcc8934db3 tzdb-2017b.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYy/QVAAoJEO2X6Q5iqn40h2cQAJhVT8aErVfu5cdjXIHn97Zr igIlZT+Q+xF5lu8cZxcW6j9bUZ9TG3PVcCnT6ujGtMr4UiTsiPeCmNXmGwtPmMez ZNloo3CBO+kaFFVCijEeNqN3ouXEMdlkfDtbdKKQ3AobQejowu+G2E9Qhmb4rjDj M5naQ+42nmB0mM1j1n4tyc6jL70gRaqSMmTUxVH4B69/GyD4Og4nuM1anfDfq26t dzhesg4q6TrdO5JJUHObH1FAYH95ZxzgVZ5jkT5N4Txl9UukpxI8u49nDfac9QeO RlvKaXcR7WQgC5fNxqvF5DKBzGmnZI4gx4CJMa+7IsjssOTsVmH1nYXsUdgR4kCf x7zH6s0buLICDRCKPr3pep/IYxj2DXYRBT5ViqMlQf3A3wGIgRUF6EPMKI1vfppv fXjdixU4HsZiJS7Epe6kcezcJrZ8n1YWEQxjFe8qYEJs08mApsSC5DGBXcBchLQI 2S6Au6d6fwqO77K7eOgj8MbYjC/Orhz8dIUGtjAjeZ/qek9ON32l0rPt2QxSnODc 43qtY2H7Uvky45J2niyOEnRbSKLSr5NZPdng4pmp376iVCGTisHJlwtRRfdfPGQo 56LUq4x3UaM3zVDHcpCLHvc7VQKYt3uVVzxbf89PN3jHZ459EqpOtM2TJIHtniw+ 8Ytju9WAEg4OscZi6VnF =B5DX -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYy/QVAAoJEO2X6Q5iqn40JJkP/2GuKex77gS9RXlx5iDbW+3x CAz6HEIcNGW2jEZCIM0zdvHH2Rw27/5CGixWWFGW4JWIQRu3Jtma4aCE++XUtYl0 +xHrnm43BmiYNUq7lNQsoGwLYTNMxvlOkk6vMBVRRQvODQGajdSgYC/D0Oc3VGG5 6X5ofl+vTyOpsDtGLtsJcqaaqE5hPf3rUfGWuEDVuwpoiKAckMoB4sNufOsf0DTT iNogrYCnGKLd4SM08xkPY56qipEONYh5u/4lZfcUCPkqtZmp3j3EVzuHS365aTwP 0jhSqTmAlCC7wL1eOQPY4Lot4WebSsdqVGqCfZCpwRfke39FCFCPHyZI8RwbIgRR gxNPV0U5V4FpjTXx1mVjv3m5ibp+4FetCKFvbtX5AKMikaGqujouOlKup899owH2 pFPQ/5O4fJGee51LQQRirnXSYftSplnu7Qz0ti2b43OIVq0JFyqkVCevoSRf1LqZ QXaDQtaVR2Vfm4p2yVD2hBwhpr/ZvTDLRAaynT8eZ1C8DUASAGA/LsplQ62x1mIO inGrNsuIs7MsSy4RAk/VruVnDeUZNnEAYE53dQB0uJHbFNo4FyOu6stp9JNy7k8X 98AuiLdnSPDmCJs69w8BqePcVxnNMgDcHbsDwaPGl/WcDEhLGFkSsHfp02QVTo1L Yi+G86lCBaDMrp4I7g5J =5tCY -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYy/QVAAoJEO2X6Q5iqn40DxIQALEkQyPnAC3PCu10cf1+wPDh vEu8fkMbZ47klCgPbj+ZdtPWRASFc+9BJcE3KiRyxgCYPnMr7XfBlXgq1bPVsl+X h3RJXsQdh8N6hGkL4hPCQ/t+/5SNfFmHudDV71KjaGpERDyAdz2/D7cPY5nGe4r6 hr7SWPO3QXzpnY7qVW7ZCifE/XEr75o5/h9xyIPJanLLltwxE/XTLlwr4yBM91Yt PMQv0bJbyZ+l13QF1P/Rtt7gsOqWuxyNuH+lyPDOC/XN3YG0sTjt8QmpM+svo863 aZVqzjdfnJ7BkQNICc9W5WShXhK6bQNk/lvRinOwXgwzY2tYeqx+jdi2AqEWJK4c xRfUDOePyrDG731oIBKb2J4p1nKuw4MZ1G5RVIHVTk6xf7QL9+1MwRLpxb/o9fOl Vt+T1RZL2v12rLu0/orokeYR3mAsme73k4zBmQODDLXkD2j4GtRLqXroTB1+3y+X njmJRIB7N2SdKx1Kvn2QOkpn+FKpJatMg1B64qGbPgVM0Cf359tHu0G0eRP2SLgI 2e0buF88i3oj9sYJ4d4Nc11qc9W4MQ8qhVG0z9rqFeMronJ5RQoBwM1OkW5ew4Ei /4QWijN0P82fAFwfHUxCzqqLrKmbVSmW80bk9o5EsX1LTOUK4UVJuYazcpIXTj7B ThCKSUwrWbJF62oTuL71 =FavL -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

2017b announcement?
by Joachim Sauer March 21, 2017

March 21, 2017

Hello, I see that the 2017b update is available for download, but I don't see an announcement in the tz-announce archive. Am I missing something? cheers Joachim

2 1

When did the subdirectory decision get made?
by Matthew Donadio March 19, 2017

March 19, 2017

The northamerica file has this note in it: # From Paul Eggert (2007-08-17): # ... # Other than Indianapolis, the Indiana place names are so nondescript # that they would be ambiguous if we left them at the 'America' level. # So we reluctantly put them all in a subdirectory 'America/Indiana'. I have gone through the mailing list archives from around this time, and also the 8/2005 timeframe (when the Indiana changes were starting to become clear), but I can't find any discussion about this, and Google is failing me. Does anyone remember when the pros and cons of using three levels for names was discussed? I just want to read up on some of that background. Thanks. --Matthew Donadio (matt(a)mxd120.com)

2 1

[PROPOSED] Richard Feynman and Mel Blanc collaborated
by Paul Eggert March 19, 2017

March 19, 2017

* tz-art.htm (Documentaries): Mention Feynman and Blanc. --- tz-art.htm | 1 + 1 file changed, 1 insertion(+) diff --git a/tz-art.htm b/tz-art.htm index 4892412..f726cce 100644 --- a/tz-art.htm +++ b/tz-art.htm @@ -26,6 +26,7 @@ briefly says why France has more time zones than Russia.</a> <li> "About Time" (1962; 53 minutes) is part of the the Bell Science extravaganza, with Frank Baxter, Richard Deacon, and Les Tremayne. +Its advisor was Richard Feynman, and it was voiced by Mel Blanc. (<a href="http://www.imdb.com/title/tt0154110/">IMDb entry</a>.)</li> </ul> <h2>Movies</h2> -- 2.7.4

1 0

Time Zones explained by Radio Free Europe
by Donald MacQueen March 19, 2017

March 19, 2017

All The Time In The World: Explaining The Mysteries Of Time Zones http://www.rferl.org/a/28375932.html

2 1

Palestine Summer Time
by Sharef Mustafa March 19, 2017

March 19, 2017

Hi, Palestine summer time will start on Mar 25th 2017 as per many local news agencies which published the news of the Palestinian cabinet meeting of March 14th which included the government decision of starting the summer time on Mar 25th 2017. However the decree it self is still not uploaded on the cabinet website, also the exact time of the shift was not mentioned, this affects Asia/Gaza & Asia/Hebron time zones, please find below links to some news sites (in Arabic) https://www.maannews.net/Content.aspx?id=897248 https://www.alwatanvoice.com/arabic/news/2017/03/14/1028254.html http://www.arn.ps/archives/194854 http://www.palsawa.com/news/2017/03/14/main/107123.html http://www.rmix.ps/archives/84243 unfortunately I did not find an English resource Regards. Sharef Mustafa

2 1

Why the Ancient Britons did not use Daylight Saving Time
by Jonathan Leffler March 17, 2017

March 17, 2017

http://www.gocomics.com/nonsequitur/2017/03/12 -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

2 1

mktime(): wrong value for DST taken?
by Kees Dekker March 14, 2017

March 14, 2017

Hi, Not sure whether it is related to mktime (see also http://mm.icann.org/pipermail/tz/2017-January/thread.html#24749) but I run into a similar issue. Consider the code below, and compile with (any) tz library (I tried with 2017A code). Save the source and compile with: gcc -o <out> <source> -L <tzdir> -ltz Running the produced exe results in: gcc -o ambigioustest2017a ambigioustest.c -L./tzcode2017a/ -ltz kdekker@nlbavlsm3.infor.com:/home/kdekker/downloads$ ./ambigioustest2017a enter mktime with: 1970/Jan/15278 00:119:30, week day: -858993460, year day: -858993460, dst: -1 the return value of mktime is: 1319957970 normalized times: 2011/Oct/30 01:59:30, week day: Sun, year day: 302, dst: 0 tz=EST, EDT Based on the provided TZ value, I expected that 01:59:30 is still in DST, and thus the returned value by mktime should be 1319954370 (i.e. one hour off). What I'm doing wrong, or what is wrong in the mktime() code? Please not that running the same source by using the built-in glibc mktime() function (i.e. gcc -o <exe> <sourcefile> and no additional flags), the result changes to: enter mktime with: 1970/Jan/15278 00:119:30, week day: -858993460, year day: -858993460, dst: -1 the return value of mktime is: 1319954370 normalized times: 2011/Oct/30 01:59:30, week day: Sun, year day: 302, dst: 1 tz=EST, EDT Note the minor differences with the previous output. Please let me know what should be correct? The provided source code is a part of our larger own test suite. Our test suite tests a wide range of values, especially near boundaries or ambiguous values. Regards, Kees /* start C-code */ #include <time.h> #include <stdio.h> int main(void) { int ret = 0; const char *months[] = { "Jan", "Feb", "Mar", "April", "May", "June", "July", "Aug", "Sep", "Oct", "Nov", "Dec" }; const char *days[] = { "Sun", "Mon", "Tue", "Wed", "Tur", "Fri", "Sat" }; // Back from daylight saving time to normal time. // In 2011, this happened October 30. // At 03:00 hours, local time was set back one hour. // So local time interval 02:00 - 03:00 hours is ambiguous: // It exists both in dayligth saving time and in normal time. putenv("TZ=EST5EDT,M4.1.0/02:00,M10.5.0/02:00"); struct tm tmp = { 30, 119, 0, 15278, 0, 70, -858993460, -858993460, -1}; printf("enter mktime with: %04d/%s/%02d %02d:%02d:%02d, week day: %d, year day: %d, dst: %d\n", tmp.tm_year + 1900, months[tmp.tm_mon], tmp.tm_mday, tmp.tm_hour, tmp.tm_min, tmp.tm_sec, tmp.tm_wday, tmp.tm_yday, tmp.tm_isdst); time_t t = mktime(&tmp); /* expect: t == 1319954370, DST is still on, because it still some seconds before 2:00 */ printf("the return value of mktime is: %lld\n", (long long)t); printf("normalized times: %04d/%s/%02d %02d:%02d:%02d, week day: %s, year day: %d, dst: %d\n", tmp.tm_year + 1900, months[tmp.tm_mon], tmp.tm_mday, tmp.tm_hour, tmp.tm_min, tmp.tm_sec, days[tmp.tm_wday], tmp.tm_yday, tmp.tm_isdst); if (t >= 0) { printf("tz=%s, %s\n", tzname[0], tzname[1]); } return 0; } /* End-of-C-Code */

2 1

Re: [tz] question about mktime_tzname()
by Kees Dekker March 14, 2017

March 14, 2017

Hi, Can anyone help me? In short, I set TZ to EST5EDT,M4.1.0/02:00,M10.5.0/02:00, which means daylight saving for EST (=GMT-5 or GMT-4 if DST is active), with switching DST at first Sunday of April and move to standard time at the last Sunday of October. The input to mktime is (See also attached source code) 1-1-1970, 19:00h (tm_min=1140 = 1140/60 = 19h) local EST time and tm_isdst set to -1. Because of this value, the tz code should figure out that 1-1-1970 is not in DST so the time difference with GMT/UTC is 5 hours. I would exect then mktime() to return 0. This is true if I use the system functions, but mktime() returns -3600 when using the tz library. The output of running the test case with system libraries is: ./tztestcase enter mktime with: 1970/Jan/00 00:1140:00, week day: -858993460, year day: -858993460, dst: -1 the return value of mktime is: 0 normalized times: 1969/Dec/31 19:00:00, week day: Wed, year day: 364, dst: 0 The output of the test case with the tz lib is: ./tztestcase2016j enter mktime with: 1970/Jan/00 00:1140:00, week day: -858993460, year day: -858993460, dst: -1 the return value of mktime is: -3600 normalized times: 1969/Dec/31 19:00:00, week day: Wed, year day: 364, dst: 1 Please correct me if I'm wrong. Is this a bug in the tz code? Please note the differences. From: Kees Dekker Sent: Thursday, January 05, 2017 15:03 To: 'tz(a)iana.org' <tz(a)iana.org> Subject: question about mktime_tzname() Hi, I'm running into a potential bug. Please also see the attached C-source file for a reproduction. Reproduction steps: 1. Build tz code, in such way that a libtz.a exists 2. Compile attached source with (e.g. on Linux): gcc -g -o tztestcase2016j tztestcase.c -L <tzlibdir> -ltz 3. Checking the same test case source code with a system library (instead of IANA libtz.a) can be achieved by omitting -L and -l flags in previous command (see #2). It does not make much sense which version of tzcode is used, I tried 2013i and 2016j and both show the same behavior. The mktime() code returns -3600, while I expect 0. Because the TZ zone is explicitly specified, EST5EDT is GMT-5. So the provided time stamp (31-Jan-1969, 19:00) is exactly the same as UTC value 0 (1-Jan-1970, 00:00 GMT). Both Linux and Windows with system libraries return 0 in this specific case (I used these for reference). The remainder of this email is based on the tzcode2016j source code (e.g. for used line numbers). The provided TZ value is parsed in tzparse() and results in sp->ttis[0] set as DST value, and sp->ttis[1] as standard time value. This is at least contrary to in the else part of the if (*name == ',' || *name == ';') block (there DST is saved in sp->ttis[1]). Just grep on init_ttinfo() calls in localtime.c. However, in localsub(), around line 1428, the i becomes sp->defaulttype (which is zero), i.e. points to the DST value of sp->ttis[], which is assigned to ttisp. As result, because t is below sp->ats[0], DST takes into effect, which is incorrect, as everything after the last Sunday in October and before the first Sunday in April (see attachment, TZ="EST5EDT,M4.1.0/02:00,M10.5.0/02:00") is assumed to be standard time. I'm not sure whether I draw the right conclusion, but because the incorrect assumption of using DST, mktime() returns -3600 (on hour off) instead of the expected 0. Is this conclusion correct? I'm not sure how to fix it. When changing the call to init_ttinfo() and effectively swapping DST and standard time (also for symmetry with the else part) in sp-ttis[] (0 to 1 and 1 to 0) + keeping sp->defaulttype = 0 solved this problem, but introduces other conversion errors around DSTchanges (I don't have yet an reproduction, but can make one if needed). The sp->default type is used (in localsub ()) when if (sp->timecnt == 0 || t < sp->ats[0]). The other approach is to assign sp->defaulttype = 1 when the init_ttinfo() calls are not swapped. Anyhow, there is a tight relationship between the value of sp->defaulttype and the order in which DST/standard times are written in sp->ttis[]. If the previous idea is incorrect (and I guess it is), additional code may be needed in time2sub() if yourtm.tm_isdst == -1. In that case, the provided data in yourtm should be checked whether DST is (or is not) into effect. The found mytm struct should match. Otherwise a DST correction is needed (one-hour shift). The current code mistakenly uses DST, and that is why (if I understand all well) mktime() now returns -3600. If I was not able to explain the issue correctly, please let me know. I'm not sure to understand what's going wrong now, but may be, the provided attachment will help in giving better understanding. Because the provided date is near 1970, quite few steps are needed to see what's happing in localtime.c. Regards, Kees Dekker PS. This email has been sent assuming that attachments will not get lost. Otherwise, just copy paste the code below and save to e.g. tztestcase.c. #ifdef _WIN32 #define _CRT_SECURE_NO_WARNINGS #endif #include <time.h> #include <stdio.h> #include <stdlib.h> int main(void) { int ret = 0; const char *months[] = { "Jan", "Feb", "Mar", "April", "May", "June", "July", "Aug", "Sep", "Oct", "Nov", "Dec" }; const char *days[] = { "Sun", "Mon", "Tue", "Wed", "Tur", "Fri", "Sat" }; /* DST switch in April in first Sunday and October, last Sunday */ putenv("TZ=EST5EDT,M4.1.0/02:00,M10.5.0/02:00"); /* January, 1970, invalid input for tm_mday (0 instead 1..31) */ /* non-normalized input for minutes: 1140/60 = 19, so 19:00 EST5EDT time, which is 5 hours before GMT, and should result in t == 0 below */ /* let system figure out whether DST is effect */ struct tm tmp = { 0, 1140, 0, 0, 0, 70, -858993460, -858993460, -1}; printf("enter mktime with: %04d/%s/%02d %02d:%02d:%02d, week day: %d, year day: %d, dst: %d\n", tmp.tm_year + 1900, months[tmp.tm_mon], tmp.tm_mday, tmp.tm_hour, tmp.tm_min, tmp.tm_sec, tmp.tm_wday, tmp.tm_yday, tmp.tm_isdst); time_t t = mktime(&tmp); /* expect: t == 0, DST is off, time is exactly at the boundary of lowest possible UTC value */ printf("the return value of mktime is: %lld\n", (long long)t); printf("normalized times: %04d/%s/%02d %02d:%02d:%02d, week day: %s, year day: %d, dst: %d\n", tmp.tm_year + 1900, months[tmp.tm_mon], tmp.tm_mday, tmp.tm_hour, tmp.tm_min, tmp.tm_sec, days[tmp.tm_wday], tmp.tm_yday, tmp.tm_isdst); if (t >= 0) { printf("tz=%s, %s\n", tzname[0], tzname[1]); } return 0; }

5 26