- tz - lists.iana.org

Mongolian time zone.
by Phake Nick Jan. 13, 2018

Jan. 13, 2018

Currently, tz database say Mongolia use UTC+7/8/9 as timezone. However, after quick google search, I found a question about time of Mongolia in a Mongolia question and answer time at [1]. The page itself is facing technical problem to me so I accessed it via Google cache which I subsequently thrown the cache into Google translate and archived the result at [2]. According to the page from 2016, three different users of the site answered the question with same answer, and all of them are saying Mongolia have three different timezone: 6, 7, 8. This is different from the information recorded in tz database. So, is the information in tz database incorrect? And then, another question on the site [3] (archived in [4]) asked about when did Mongolia start officially using the world time and someone answered since 1997. What does that mean? (On the other hand, another answer to a similar question say 1961... [5][6] or is that an error in machine translation?) [1]: http://acyy.mn/3379/монгол-улс-хэд-хэддүгээр-цагын-бүсэд-оршдог-вэ [2]: http://archive.is/y3jpH [3]: http://acyy.mn/8620/монгол-хэдэн-оноос-дэлхийн-бүсийн-цагийг-хэрэглэж-эхлэс… [4]: http://archive.is/PQBVk [5]: http://acyy.mn/7379/му-хэдэн-оноос-дэлхийн-цагийг-баримтлах-болсон-бэ [6]: http://archive.is/e39nW

2 1

Sao Tome Principe change of time zone
by Steffen Thorsen Jan. 9, 2018

Jan. 9, 2018

Multiple sources tell that Sao Tome changed from UTC to UTC+1 as they entered the year 2018: https://www.dn.pt/lusa/interior/relogios-avancam-uma-hora-em-sao-tome-e-pri… http://pt.rfi.fr/sao-tome-e-principe/20180101-sao-tome-e-principe-muda-de-h… http://www.stp-press.st/2017/12/23/sao-tome-e-principe-vai-mudar-hora-a-par… So it seems the Africa/Sao_Tome zone needs to activated again! Our English summary: https://www.timeanddate.com/news/time/sao-tome-principe-time-zone-change.ht… Best regards, Steffen Thorsen - timeanddate.com

3 3

[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