- tz - lists.iana.org

question about mktime_tzname()
by Kees Dekker Jan. 5, 2017

Jan. 5, 2017

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; }

1 0

Definition for timezone Asia/Urumqi and Asia/Kashgar, CST, and other questions about Chinese timezones.
by gfb hjjhjh Jan. 5, 2017

Jan. 5, 2017

1. Currently, Asia/Urumqi and Asia/Kashgar are defined as UTC+6, covering most of Xinjiang and Tibet. However, from brief search result, I cannot see any indication about the UTC+6 usage by ethnic non-han in Xinjiang also exists in Tibet, and Lhasa resident daily activities are apparently only one hours later than those in inner China too. The official announcement about UTC+6 usage in Xinjiang also does not cover Tibet. Thus it seems like those UTC+6 timezones in tz database should not cover Tibet. However, there might be some undocumented official announcement or on the ground usage that I does not notice and require further validation. 2. Actually, which file define the boundary of timezones in tz database? I see they are in comments for China but how about generally? 3. And given Asia/Urumqi is currently defined differently from Asia/Shanghai, and Maoming, Guandong is now using UTC+8, no matter what historical reason might be behind the consideration of putting Maoming, Guangdong in Asia/Urumqi, its current time usage along should have justified putting it in Asia/Shanghai instead 3.a. In http://mm.icann.org/pipermail/tz/2006-July/013704.html , it said Maoming and etc. are in Xinjiang tinezone with data from astro.com but I cannot find anywhere on the site that include historical timezone info and what are their sources? 4. as the name "Central Standard Time" in China was created by ROC, the current main use of this term is for the time in Taiwan and thus it might be unsuitable to use the name for timzone in mainland china area. 5. Why there are 5 different zones in China when the theory file say "if all the clocks in the region have agreed since 1970, don't bother to inclide more than one location even if subregions' clocks disagreed before 1970" ?

5 7

zdump broken with -DUSE_LTZ=0
by Joseph Myers Dec. 21, 2016

Dec. 21, 2016

I tried updating the copy of tzcode in glibc. I found that as of the latest release and current git, zdump doesn't build with -DUSE_LTZ=0, because that configuration disables the inclusion of private.h, which defines the INITIALIZE macro which zdump now uses unconditionally. (There's also a -Wundef issue with the "#if !HAVE_POSIX_DECLS", as that's also only defined in private.h, but that's easy to work around.) -- Joseph S. Myers joseph(a)codesourcery.com

2 1

Minor fixes to commentary
by Tim Parenti Dec. 19, 2016

Dec. 19, 2016

The attached patch fixes a few minor issues left in commentary, and also adds a note about the constructed lines for America/Montevideo which currently work around the non-prevalence of zic which supports %z. -- Tim Parenti

2 1

Proposal: validation text file with releases
by Jon Skeet Dec. 19, 2016

Dec. 19, 2016

Background: I'm the primary developer for Noda Time <http://nodatime.org> which consumes the tz data. I'm currently refactoring the code to do this... and I've come across some code (originally ported from Joda Time) which I now understand in terms of what it's doing, but not exactly why. For a little while now, the Noda Time source repo has included a text dump file <https://github.com/nodatime/nodatime/blob/master/src/NodaTime.Test/TestData…>, containing a text dump of every transition (up to 2100, at the moment) for every time zone. It looks like this, picking just one example: Zone: Africa/Maseru LMT: [StartOfTime, 1892-02-07T22:08:00Z) +01:52 (+00) SAST: [1892-02-07T22:08:00Z, 1903-02-28T22:30:00Z) +01:30 (+00) SAST: [1903-02-28T22:30:00Z, 1942-09-20T00:00:00Z) +02 (+00) SAST: [1942-09-20T00:00:00Z, 1943-03-20T23:00:00Z) +03 (+01) SAST: [1943-03-20T23:00:00Z, 1943-09-19T00:00:00Z) +02 (+00) SAST: [1943-09-19T00:00:00Z, 1944-03-18T23:00:00Z) +03 (+01) SAST: [1944-03-18T23:00:00Z, EndOfTime) +02 (+00) I use this file for confidence when refactoring my time zone handling code - if the new code comes up with the same set of transitions as the old code, it's probably okay. (This is just one line of defence, of course - there are unit tests, though not as many as I'd like.) It strikes me that having a similar file (I'm not wedded to the format, but it should have all the same information, one way or another) released alongside the main data files would be really handy for *all* implementors - it would be a good way of validating consistency across multiple platforms, with the release data being canonical. For any platforms which didn't want to actually consume the rules as rules, but just wanted a list of transitions, it could even effectively replace their use of the data. One other benefit: diffing the dump between two releases would make it clear what had changed in *effect*, rather than just in terms of rules. One sticking point is size. The current file for Noda Time is about 4MB, although it zips down to about 300K. Some thoughts around this: - We wouldn't need to distribute it in the same file as the data - just as we have data and code file, there could be a "textdump" file or whatever we'd want to call it. These could be retroactively generated for previous releases, too. - As you can see, there's redundancy in the format above, in that it's a list of "zone intervals" (as I call them in Noda Time) rather than a list of transitions - the end of each interval is always the start of the next interval. - For zones which settle into an infinite daylight saving pattern, I currently generate from the start of time to 2100 (and then a single zone interval for the end of time as Noda Time understands it; we'd need to work out what form that would take, if any). If we decided that "year of release + 30 years" was enough, that would cut down the size considerably. Any thoughts? If the feeling is broadly positive, the next step would be to nail down the text format, then find a willing victim/volunteer to write the C code. (You really don't want me writing C...) Jon

18 92

[PROPOSED] Pacify ‘make check_character_set’
by Paul Eggert Dec. 19, 2016

Dec. 19, 2016

* tz-art.htm: Convert to ASCII. --- tz-art.htm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tz-art.htm b/tz-art.htm index de56b07..296a2d9 100644 --- a/tz-art.htm +++ b/tz-art.htm @@ -376,12 +376,13 @@ line is "Lights go out and I can't be saved".</td></tr> <tr><td> </td></tr> <tr><td>Artist</td><td>Jaime Guevara</td></tr> -<tr><td>Song</td><td><a href="https://www.youtube.com/watch?v=ZfN4Fe_A50U">Qué +<tr><td>Song</td><td><a +href="https://www.youtube.com/watch?v=ZfN4Fe_A50U">Qué hora es</a></td></tr> <tr><td>Date</td><td>1993</td></tr> <tr><td>Total Time</td><td>3:04</td></tr> <tr><td>Notes</td><td>The song protested "Sixto Hour" in Ecuador -(1992–3). Its lyrics include "Amanecía en mitad de la noche, los +(1992–3). Its lyrics include "Amanecía en mitad de la noche, los guaguas iban a clase sin sol" ("It was dawning in the middle of the night, the buses went to class without sun"). <tr><td> </td></tr> -- 2.7.4

1 0

Havranek et al. on DST's effect on energy consumption
by Paul Eggert Dec. 18, 2016

Dec. 18, 2016

A recent meta-analysis of energy savings due to daylight-saving time found a mean effect close to zero (the weighted mean of 0.343% was less than the estimated standard error). The largest energy savings from DST was found in high-latitude countries; areas closer to the equator tended to have negative energy savings. Studies published in journals with high impact factors tended to be more pessimistic about energy-savings benefits. The study concluded, "the effects of daylight saving time on energy consumption are too small to justify the biannual time-shifting." Havranek T, Herman D, Irsova Z. Does daylight saving save energy? a meta-analysis. MPRA Paper No. 74518 (2016-10-12). https://mpra.ub.uni-muenchen.de/74518/1/MPRA_paper_74518.pdf

1 0

Re: [tz] Request to add entry to "Programmatic interfaces that map geographical coordinates"
by Evan Siroky Dec. 16, 2016

Dec. 16, 2016

The package tz-lookup and geo-tz are independent of each other. As far as I know, the major difference between the two is the data source that is used. geo-tz is released under the MIT license. Feel free to link to the timezone tag. Although in my opinion a lot of the packages aren't the best because they don't get updated frequently enough with changes to the timezone db. Evan On Saturday, 10 December 2016, 12:02, Paul Eggert <eggert(a)cs.ucla.edu> wrote: Evan Siroky via tz wrote: > I maintain a node.js library that looks up the timezone name at a GPS coordinate. The project is called geo-tz: https://www.npmjs.com/package/geo-tz My library uses data produced from timezone-boundary-builder. Can you please add an entry to tz-link.html for my project? What's a good way to do that? Currently tz-link.htm says: <li>The <a href="https://www.npmjs.com/package/tz-lookup">tz-lookup module</a> for <a href="https://nodejs.org/en/">Node.js</a> is in the public domain.</li> How should the relationship between tz-lookup and geo-tz be described? Also, what's the license for geo-tz? It is not obvious from its web page. In looking at <https://www.npmjs.com/browse/keyword/timezone> I see several more Node.js time zone packages that seem relevant. Perhaps we should link to that page?

3 6

Spain may change time
by Steve Allen Dec. 15, 2016

Dec. 15, 2016

Lots of news agencies are picking up a possible change of time in Spain. http://www.reuters.com/article/spain-timezone-idUSL5N1E744D -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

11 18

Ecuador DST in 1992/93
by Alois Treindl Dec. 15, 2016

Dec. 15, 2016

A client born in Ecuador wrote to me: "I need a little help with something plus I don't know who else can help me besides Astro! When I was born, the President of Ecuador changed the time zone (one hour ahead) from Nov/28/1992 to Feb/05/1993 because of problems with energy and there were a lot of power cuts across the country. " I checked the tzdata/southamerica file which holds for Ecuador: # Ecuador # # Milne says the Central and South American Telegraph Company used -5:24:15. # # From Paul Eggert (2007-03-04): # Apparently Ecuador had a failed experiment with DST in 1992. # <http://midena.gov.ec/content/view/1261/208/> (2007-02-27) and # <http://www.hoy.com.ec/NoticiaNue.asp?row_id=249856> (2006-11-06) both # talk about "hora Sixto". Leave this alone for now, as we have no data. # # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Guayaquil -5:19:20 - LMT 1890 -5:14:00 - QMT 1931 # Quito Mean Time -5:00 - ECT # Ecuador Time The two links in the comment to not work. I search the web and came up with this link: http://www.elcomercio.com/actualidad/hora-sixto-1993.html which says: Al inicio de su mandato, el Gobierno Nacional, mediante Decreto Presidencial no. 285, obligó que todos los ecuatorianos adelantaran una hora en sus relojes para “ aprovechar la luz solar” y disminuir el consumo de energía. Fue la llamada ‘hora de Sixto’, que se aplicó desde el 28 de noviembre de 1992 hasta el 5 de febrero de 1993. Incluso, los estudiantes de todos los niveles educativos estuvieron obligados a iniciar clases a las 06:00 y terminar antes del mediodía. Google translation: At the beginning of his term, the National Government, through Presidential Decree no. 285, forced all Ecuadorians to advance an hour in their watches to "take advantage of sunlight" and reduce energy consumption. It was the so-called 'Sixtus hour', which was applied from November 28, 1992 until February 5, 1993. Even students of all educational levels were forced to start classes at 06:00 and finish before midday. There should probably be a rule: Rule ECU 1992 only - Nov 28 0:00 1:00 S Rule ECU 1993 only - Feb 5 0:00 0 - and the last lines of the existing entry should refer to this rule. Whether the law applied also to Galapagos, I do not know.

3 4