- tz - lists.iana.org

[PATCH] * northamerica: Add note re Chicago time before 1883.
by Paul Eggert Jan. 8, 2018

Jan. 8, 2018

--- northamerica | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/northamerica b/northamerica index 505300a..a014126 100644 --- a/northamerica +++ b/northamerica @@ -348,6 +348,18 @@ Zone America/New_York -4:56:02 - LMT 1883 Nov 18 12:03:58 # Nebraska, eastern North Dakota, Oklahoma, eastern South Dakota, # western Tennessee, most of Texas, Wisconsin +# From Paul Eggert (2018-01-07): +# In 1869 the Chicago Astronomical Society contracted with the city to keep +# time. Though delayed by the Great Fire, by 1880 a wire ran from the +# Dearborn Observatory (on the University of Chicago campus) to City Hall, +# which then sent signals to police and fire stations. However, railroads got +# their time signals from the Allegheny Observatory, the Madison Observatory, +# the Ann Arbor Observatory, etc., so their clocks did not agree with each +# other or with the city's official time. The confusion took some years to +# clear up. See: +# Moser M. How Chicago gave America its time zones. Chicago. 2018-01-04. +# http://www.chicagomag.com/city-life/January-2018/How-Chicago-Gave-America-I… + # From Larry M. Smith (2006-04-26) re Wisconsin: # https://docs.legis.wisconsin.gov/statutes/statutes/175.pdf # is currently enforced at the 01:00 time of change. Because the local -- 2.7.4

1 0

Three time zones meeting at one location
by Paul Eggert Dec. 29, 2017

Dec. 29, 2017

In yesterday's My Modern Met, Jessica Stewart says that in over 20 locations in the world, three different time zones converge. Surveyor Generals Corner in Australia and Treriksrøysa (for the point where Finland, Norway, and Russia meet) are two examples. For time zone hounds it may be an amusing read, if only to spot the mistakes. Stewart J. Places around the world where three time zones meet in the same spot. My Modern Met. 2017-12-28. https://mymodernmet.com/three-different-time-zones-facts/

1 0

Lithuania calls on EU to stop adjusting clocks for daylight savings
by Lord Buddha Dec. 23, 2017

Dec. 23, 2017

https://www.theguardian.com/world/2017/dec/22/lithuania-calls-on-eu-to-stop…

1 0

Transitions after those included in zoneinfo binaries?
by Paul G Dec. 21, 2017

Dec. 21, 2017

I recently noticed a discrepancy between the python-dateutil and pytz libraries when calculating offsets for dates after the last included transition in the zonefile binaries. What it boils down to is that when it runs out of transitions, python-dateutil selects the "standard" offset and pytz assumes that after the last transition the value "holds". In the southern hemisphere, this produces two different behaviors. Obviously there's no "right" answer here, since these are predictions about what time zones will be applied 20 years in the future (and even if the rules stayed the same, the "end date" is entirely artificial). Still, I wonder if it might be worth a bit of discussion and possibly a note in the Theory file? Barring a representation of the data that exposes the rules directly (in which case no such artificial limitation would be necessary), I think either fallback is defensible. Best, Paul

7 10

Complexities of time rendered graphically
by Steve Jones Dec. 19, 2017

Dec. 19, 2017

Folks: Today's XKCD comic is amusing: https://xkcd.com/1930/ Steve Jones [image: Emacs!]

3 5

default value of TZDEFAULT
by scs＠eskimo.com Dec. 18, 2017

Dec. 18, 2017

[This is a tzcode issue, not tzdata. Your regular discussion of zone definition and naming issues will resume shortly. :-) ] Consider this simple little program: #include <stdio.h> #include <time.h> int main() { time_t t = time(NULL); struct tm *tmp = localtime(&t); puts(asctime(tmp)); return 0; } There's nothing special about this program (that's the point). But suppose I download tzcode or tzdb and then compile the little program (call it lt.c) along with a just-built localtime(), like this: make localtime.o cc -o lt lt.c localtime.o But if I then run 'lt', it is likely not to work -- there's a pretty good chance it will print the current time in UTC, not my local time zone. If it fails, one reason is that it didn't successfully find my system's already-installed tz files. (That is, I made no attempt to build or install any new tz files.) The reason it didn't find them is obvious enough, and the Makefile contains all the hints I need: TOPDIR= /usr/local # "Compiled" time zone information is placed in the "TZDIR" directory # (and subdirectories). # Use an absolute path name for TZDIR unless you're just testing the software. # TZDIR_BASENAME should not contain "/" and should not be ".", ".." or empty. TZDIR_BASENAME= zoneinfo TZDIR= $(TOPDIR)/etc/$(TZDIR_BASENAME) And, sure enough, on my system, the already-installed tz files are not in /usr/local, they're in /usr/share. So it looks like if I change TOPDIR to /usr/share, or TZDIR to /usr/share/zoneinfo, I should be able to fix it. But no! It still doesn't work, and the reason is, my user environment doesn't have the TZ environment variable set; I'm assuming that the system's default time zone will be used. And, out of the box, the tzcode distribution assumes that the local time zone is defined by a file 'localtime' *in TZDIR*; that is, it essentially assumes that TZDEFAULT is $TZDIR/localtime. But some (perhaps even many) systems put it in /etc/localtime. That's where my (MacOS) system puts it, and a lot of Linux systems put it there, too. The upshot is that on such a system, if you compile and use localtime.c straight out of the tzcode distribution, it won't find your localtime file, and will end up falling back to UTC unless TZ is set. Since the Makefile already lets you set your own version of TZDIR (overriding the setting in tzfile.h), I think it makes sense to do the same thing for TZDEFAULT. Patch attached. With this patch in place, and with the Makefile edited to say TZDEFAULT = "/etc/localtime" fresh compiles of localtime.o correctly find my system's localtime file, and the lt program finally prints local time, as expected. (This tweak to TZDEFAULT's usage helps the extraction case -- that is, when the code tries to fetch the default zone, but not necessarily the tz file building case. I'm not sure whether 'make install' will do the right thing when TZDEFAULT is set, but it definitely doesn't do the right thing if DESTDIR and TZDEFAULT are both set. Is using DESTDIR supported? The Makefile should probably document it if so.) Diagnosing problems involving misconfigured TZDIR and TZDEFAULT variables can be surprisingly difficult. The localtime code doesn't have any way of telling you it's having trouble finding tz files in general, or the localtime file in particular. I'll address that issue in a separate thread. Steve Summit scs(a)eskimo.com

4 10

setting TZ and calling localtime_r
by scs＠eskimo.com Dec. 18, 2017

Dec. 18, 2017

There's code in tzcode (and, I suspect not coincidentally, glibc's localtime implementation as well) to not call the internal version of tzset on calls to localtime_r, but rather only on calls to localtime. The justification is that Posix says localtime_r doesn't need to update the global tzname variable. I don't have a copy of the Posix spec handy, so I can't check: does Posix also say that localtime_r doesn't need to check for and make use of a possibly-changed value of TZ? As implemented (both in tzcode and glibc), it doesn't. If a program calls localtime, then calls setenv to set a new value of TZ, then calls localtime again, it works as expected, but if it calls localtime_r, setenv, localtime_r, it doesn't. (The workaround, of course, is to call localtime_r, setenv, tzset, localtime_r.)

5 4

Kyiv
by gocdoms gocdoms Dec. 18, 2017

Dec. 18, 2017

Hello! City Kyiv is not Kiev. The *founder* of Kyiv is *Kyi*. Not Kie! Please see attached picture.

14 24

Asia/Shanghai (was: Re: Kyiv)
by Phake Nick Dec. 15, 2017

Dec. 15, 2017

Speaking of which, after reading naming convention of zones, wouldn't it still be better to rename the zone to Asia/Beijing mowadays? As almost all users are referring to the zone as "Beijing Time", if in any case there are different time standard emerge that caused Beijing and Shamghai to use different tome standard instead, then it would be more likely for the zone's user to think the Beijing time is a time being continued while Shanghai time would be another new time. In order to reflect the line of thinking and thus when future communication or ammendment easier when things really do change, would such renaming make sense? 2017年12月16日 03:20 於 "Garrett Wollman" <wollman(a)csail.mit.edu> 寫道： > > Contrast the case (which thankfully we do not have to deal with) of > the capital city of the People's Republic of China. In English, it > used to be called "Peking", and in fact in the name of the university > and of the duck dish it still is. The PRC government made a concerted > campaign to change the name used by English speakers to be "Beijing", > which is a phonetic representation of the name of the city in Mandarin > (putonghua). This has to a very large extent worked, and now most > English texts say "Beijing" and not "Peking" (although many people > still don't pronounce it "correctly" because the letters in hanyu > pinyin don't have the same sound values as they do in English). > However, in many languages *other than English*, the name of the city > has not changed -- AFAIK it's still "Pékin" in French, for example.

3 2

tzdata gpg key
by Zura Kutchava Dec. 8, 2017

Dec. 8, 2017

Dear Friends, On https://data.iana.org/time-zones/releases/ I found packages and signatures, but cannot find gpg key to veryfing them. Can you be so kind to tell me where is gpg key for verifying? I am building linux from scratch and writing script for downloading and verifying main packages, so your help will be very important. Thanks beforehand, Regards.

2 1