
And now, the update. These changes arrange things so that binary files include "transition" entries for minimum time values; these entries eliminate localtime guesswork in handling low-valued time stamps. The bad news: binary files grow slightly as a result of these changes. The good news: there are no changes in the output of "zdump -v" applied to before-and-after versions of all the binary files generated by a "make install." Changes are attached and appear in mangled form below; these are relative to the github version of zic.c after the rollback in the earlier message today. @dashdashado 1.2 2805 lines 1.4 2813 lines *** /tmp/,azic.c 2014-05-01 01:51:36.998933800 -0400 --- /tmp/,bzic.c 2014-05-01 01:51:37.092534000 -0400 *************** *** 1480,1493 **** fromi = 0; while (fromi < timecnt && attypes[fromi].at < min_time) ++fromi; - if (isdsts[0] == 0) - while (fromi < timecnt && attypes[fromi].type == 0) - ++fromi; /* handled by default rule */ for ( ; fromi < timecnt; ++fromi) { ! if (toi != 0 && ((attypes[fromi].at + gmtoffs[attypes[toi - 1].type]) <= ! (attypes[toi - 1].at + gmtoffs[toi == 1 ? 0 ! : attypes[toi - 2].type]))) { attypes[toi - 1].type = attypes[fromi].type; continue; --- 1480,1490 ---- fromi = 0; while (fromi < timecnt && attypes[fromi].at < min_time) ++fromi; for ( ; fromi < timecnt; ++fromi) { ! if (toi > 1 && ((attypes[fromi].at + gmtoffs[attypes[toi - 1].type]) <= ! (attypes[toi - 1].at + ! gmtoffs[attypes[toi - 2].type]))) { attypes[toi - 1].type = attypes[fromi].type; continue; *************** *** 1532,1537 **** --- 1529,1541 ---- --timecnt32; ++timei32; } + /* + ** Output an INT32_MIN "transition" if appropriate--see below. + */ + if (timei32 > 0 && ats[timei32] > INT32_MIN) { + --timei32; + ++timecnt32; + } while (leapcnt32 > 0 && !is32(trans[leapcnt32 - 1])) --leapcnt32; while (leapcnt32 > 0 && !is32(trans[leapi32])) { *************** *** 1698,1704 **** #undef DO for (i = thistimei; i < thistimelim; ++i) if (pass == 1) ! puttzcode(ats[i], fp); else puttzcode64(ats[i], fp); for (i = thistimei; i < thistimelim; ++i) { unsigned char uc; --- 1702,1713 ---- #undef DO for (i = thistimei; i < thistimelim; ++i) if (pass == 1) ! /* ! ** Output an INT32_MIN "transition" ! ** if appropriate--see above. ! */ ! puttzcode(((ats[i] < INT32_MIN) ? ! INT32_MIN : ats[i]), fp); else puttzcode64(ats[i], fp); for (i = thistimei; i < thistimelim; ++i) { unsigned char uc; *************** *** 2176,2183 **** if (usestart) { addtt(starttime, type); usestart = FALSE; ! } else if (stdoff != 0) ! addtt(min_time, type); } else for (year = min_year; year <= max_year; ++year) { if (useuntil && year > zp->z_untilrule.r_hiyear) break; --- 2185,2191 ---- if (usestart) { addtt(starttime, type); usestart = FALSE; ! } else addtt(min_time, type); } else for (year = min_year; year <= max_year; ++year) { if (useuntil && year > zp->z_untilrule.r_hiyear) break;

Thanks for fixing that. I installed those patches into the experimental github repository, along with the attached news item for this.

Hi, On 2014-05-01 16:38, Paul Eggert wrote:
Thanks for fixing that. I installed those patches into the experimental github repository, along with the attached news item for this.
From ebd01ad62ec849fbb6fcda66df4c3e1df1e53d61 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Thu, 1 May 2014 16:36:16 -0700 Subject: [PATCH] * NEWS: Document zic change for low-valued time stamps.
--- NEWS | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/NEWS b/NEWS index 1ef2764..2c289f5 100644 --- a/NEWS +++ b/NEWS @@ -5,6 +5,9 @@ Unreleased, experimental changes
Changes affecting code
+ zic now generates transitions for minimum time values, eliminating guesswork + when handling low-valued time stamps. (Thanks to Arthur David Olson.) +
Sorry to come back to this patch so long after it has been committed. It happens that this patch causes the generated zoneinfo files to not behave correctly wrt daylight saving time on 32-bit machines. On 64-bit machines or before this patch one get: $ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 13:30:00 PDT 2006 With this patch on 32-bit machines, one get: $ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 12:30:00 PST 2006 As you can see the daylight saving time is not applied. I don't know if it is a problem in zic or a problem on the GNU libc which doesn't correctly interpret the file. This is reproducible with GNU libc from git as the date of today. Any help would be appreciated. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net

The TZ string "PST+8PDT" doesn't conform to POSIX, and it isn't the name of a tzdata file. Traditionally the GNU C library attempts to interpret ruleless TZ strings by applying the daylight-saving rules of the GNU project headquarters in Cambridge, MA. It does this by combining the specified UTC offset (here, -08) with the DST rules taken from the file "America/New_York". Apparently this combination isn't working for the new-format tzdata files. My guess is that it's a glibc bug but I haven't investigated the details. You might also try using a valid POSIX string, or a valid tzdata string, and checking whether the bug also occurs in these more-important cases.

On 03/02/16 23:02, Paul Eggert wrote:
The TZ string "PST+8PDT" doesn't conform to POSIX,
It doesn't? -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Web: http://www.mev.co.uk/ )=-

On 2016-03-02 16:19, Ian Abbott wrote:
On 03/02/16 23:02, Paul Eggert wrote:
The TZ string "PST+8PDT" doesn't conform to POSIX, It doesn't?
It does appear to conform - see: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_... under TZ: "If preceded by a '-', the timezone shall be east of the Prime Meridian; otherwise, it shall be west (which may be indicated by an optional preceding '+' )." -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

On Mar 2, 2016, at 3:50 PM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
On 2016-03-02 16:19, Ian Abbott wrote:
On 03/02/16 23:02, Paul Eggert wrote:
The TZ string "PST+8PDT" doesn't conform to POSIX, It doesn't?
It does appear to conform - see:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_...
under TZ:
"If preceded by a '-', the timezone shall be east of the Prime Meridian; otherwise, it shall be west (which may be indicated by an optional preceding '+' )."
And from a quick look at whatever version of tzcode source I have, tzcode supports it. However, as I remember, glibc has its own time zone handling code, separate from tzcode; whether *it* handles "PST+8PDT" is another matter.

Brian Inglis wrote:
On 2016-03-02 16:19, Ian Abbott wrote:
On 03/02/16 23:02, Paul Eggert wrote:
The TZ string "PST+8PDT" doesn't conform to POSIX, It doesn't?
It does appear to conform - see:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_...
It "conforms" in the sense that its syntax matches the POSIX spec. However, no semantics are specified by POSIX for what daylight-saving rules are in effect when TZ="PST+8PDT" is in the environment. Glibc is within its rights, for example, to assume that DST in effect only one second during the year -- or even not in effect any time. I vaguely recall older versions of POSIX not allowing the syntax "PST+PDT", though I could be wrong. I imagine the current POSIX spec is simply a typo, since I can't imagine that it's intended for users to employ a syntax whose semantics are unspecified. Also, I think it's a glibc bug, in the sense that I don't think the current behavior is intended by the glibc maintainers. Still, portable programs shouldn't use TZ="PST+8PDT" or TZ="PST8PDT" or anything like that.

On Mar 2, 2016, at 6:08 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Brian Inglis wrote:
On 2016-03-02 16:19, Ian Abbott wrote:
On 03/02/16 23:02, Paul Eggert wrote:
The TZ string "PST+8PDT" doesn't conform to POSIX, It doesn't?
It does appear to conform - see:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_...
It "conforms" in the sense that its syntax matches the POSIX spec. However, no semantics are specified by POSIX for what daylight-saving rules are in effect when TZ="PST+8PDT" is in the environment. Glibc is within its rights, for example, to assume that DST in effect only one second during the year -- or even not in effect any time.
The same, of course, applies to PST8PDT and so on; it's not as if the "+" is somehow magical. (I presume Aurelien put it in there to force the glibc time zone code *not* to treat the TZ value as a tzdb compiled file name.)
I vaguely recall older versions of POSIX not allowing the syntax "PST+PDT", though I could be wrong. I imagine the current POSIX spec is simply a typo, since I can't imagine that it's intended for users to employ a syntax whose semantics are unspecified.
"Typo" as in "the string 'stdoffset[dst[offset][,start[/time],end[/time]]]' was intended to be 'stdoffset[dst[offset],start[/time],end[/time]]', but somebody accidentally put the square brackets in wrong", so that the you can omit everything after "stdoffset", or you can have "dst..." and omit the offset and/or the end times, but if you specify "dst" you can't omit the start and end values"?
Also, I think it's a glibc bug, in the sense that I don't think the current behavior is intended by the glibc maintainers. Still, portable programs shouldn't use TZ="PST+8PDT" or TZ="PST8PDT" or anything like that.
What about portable users? :-)

Guy Harris wrote:
The same, of course, applies to PST8PDT and so on; it's not as if the "+" is somehow magical.
Yes.
"Typo" as in "the string 'stdoffset[dst[offset][,start[/time],end[/time]]]' was intended to be 'stdoffset[dst[offset],start[/time],end[/time]]', but somebody accidentally put the square brackets in wrong", so that the you can omit everything after "stdoffset", or you can have "dst..." and omit the offset and/or the end times, but if you specify "dst" you can't omit the start and end values"?
Yes. The idea is that if you put in the dst substring, you must also append rules. Otherwise there are no rules.

On Wed, Mar 2, 2016, at 21:47, Paul Eggert wrote:
Guy Harris wrote:
The same, of course, applies to PST8PDT and so on; it's not as if the "+" is somehow magical.
Yes.
"Typo" as in "the string 'stdoffset[dst[offset][,start[/time],end[/time]]]' was intended to be 'stdoffset[dst[offset],start[/time],end[/time]]', but somebody accidentally put the square brackets in wrong", so that the you can omit everything after "stdoffset", or you can have "dst..." and omit the offset and/or the end times, but if you specify "dst" you can't omit the start and end values"?
Yes. The idea is that if you put in the dst substring, you must also append rules. Otherwise there are no rules.
Er... As far as I know, the documented behavior of tzcode itself is to use the DST rules specified in the file "posixrules" (by default an alias for America/New_York) - I had assumed that glibc did the same. Are you saying that the _actual intent_ of the POSIX committee was to forbid the use of the traditional System III timezone format, rather than allowing it (as the brackets imply) and having the rules be implementation-defined? The placement of brackets matches the not-entirely-nonsensical idea of "Allow both the System V format and the new committee-invented format" so closely that it's hard to believe that that wasn't, at least, the understanding of the person who typeset the document, even if it wasn't the intent of the committee. A mere typo, on the other hand, likely wouldn't have resulted in balanced brackets.

On 03/02/2016 09:38 PM, Random832 wrote:
Are you saying that the_actual intent_ of the POSIX committee was to forbid the use of the traditional System III timezone format, rather than allowing it (as the brackets imply) and having the rules be implementation-defined?
That's what I was saying, yes, but it appears I was incorrect. The original intent was to allow the syntax TZ='PST8PDT', but to leave the daylight-saving rules unspecified in this case. Hence the test case that prompted this thread (though most likely illustrating a bug in glibc) does not illustrate a violation of POSIX, because portable programs should not assume that TZ strings like 'PST8PDT' have any particular behavior with respect to when DST starts and stops. This is all stated clearly in the rationale for POSIX 1003.1-1988. I guess that part of the rationale has been discareded in more recent editions of the standard, which makes the current standard confusing (it confused *me*, anyway). Quoting from B8.1.1, page 267: "Rules of the form AAAn or AAAnBBB (the style used in many historical implementations) do not carry with them any statement about the start and end of daylight time.... An implementation may provide those rules in any way it sees fit, as long as the constraints implied by the TZ string as provided by the user are met. Specifically the implementation may use the string as an index into a table, which may reside either on disk or in memory. Such tables could contain rules which are sensitive to the year to which they are supplied, again since the user did not specify the exact rule.... "There is at least one public domain time zone implementation (the Olson/Harris method) that uses non-specific TZ strings and a table, as described above and handles all the general time zone problems mentioned above.... Nothing precludes the implementation from adding information beyond that given by the user in the TZ string." To try to save Guy Harris some time in reply, I should mention that there is an attribution error in rationale quoted above. As Guy wrote on 1991-09-25 in comp.unix.misc, "It is referred to as the 'Olson/Harris' method by the rationale for section B.8.1.1 in the POSIX 1003.1 spec, but as the 'Harris' in question, I'd prefer it just be called the 'Arthur Olson' method; it was Arthur's idea, and while I was *one* of the contributors to the implementation, other contributors provided at least as much stuff as I did." <https://groups.google.com/forum/?_escaped_fragment_=msg/comp.unix.misc/-ipgF...>.

On Mar 3, 2016, at 8:37 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 03/02/2016 09:38 PM, Random832 wrote:
Are you saying that the_actual intent_ of the POSIX committee was to forbid the use of the traditional System III timezone format, rather than allowing it (as the brackets imply) and having the rules be implementation-defined?
That's what I was saying, yes, but it appears I was incorrect. The original intent was to allow the syntax TZ='PST8PDT', but to leave the daylight-saving rules unspecified in this case. Hence the test case that prompted this thread (though most likely illustrating a bug in glibc) does not illustrate a violation of POSIX, because portable programs should not assume that TZ strings like 'PST8PDT' have any particular behavior with respect to when DST starts and stops.
And neither should users, unless they happen to know how the platforms they're using work.
This is all stated clearly in the rationale for POSIX 1003.1-1988. I guess that part of the rationale has been discareded in more recent editions of the standard, which makes the current standard confusing (it confused *me*, anyway).
I think I'll file a defect report on that; it either needs to explicitly say, in the standard itself, that the behavior, if you omit the DST start and end information, is undefined or implementation-defined (I leave it up to them to choose), or explicitly require a particular behavior.
To try to save Guy Harris some time in reply, I should mention that there is an attribution error in rationale quoted above.
Thanks. Dunno why they ignored, for example, Chris Torek, Mary (Mark) Horton, Robert Elz, Dennis Mumaugh, Bob Devine, Bob Toxen, or Ron Tolley, to list the folks other than Olson and Harris given as people "currently on the list" in Arthur's "seismo!elsie!tz ; new versions of time zone stuff" message from November 1986.

On 2016-03-02 18:43, Guy Harris wrote:
On Mar 2, 2016, at 6:08 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Brian Inglis wrote:
On 2016-03-02 16:19, Ian Abbott wrote:
On 03/02/16 23:02, Paul Eggert wrote:
The TZ string "PST+8PDT" doesn't conform to POSIX, It doesn't?
It does appear to conform - see:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_...
It "conforms" in the sense that its syntax matches the POSIX spec. However, no semantics are specified by POSIX for what daylight-saving rules are in effect when TZ="PST+8PDT" is in the environment. Glibc is within its rights, for example, to assume that DST in effect only one second during the year -- or even not in effect any time.
The same, of course, applies to PST8PDT and so on; it's not as if the "+" is somehow magical. (I presume Aurelien put it in there to force the glibc time zone code *not* to treat the TZ value as a tzdb compiled file name.)
This value is part of the mercurial testsuite, which now fails to pass on 32-bit machines due to this issue. It passes on 64-bit machines, so I guess that's why the problem hasn't been encountered by the developers. See: https://selenic.com/hg/file/e96d2956eb4a/tests/test-parse-date -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net

On Mar 2, 2016, at 2:41 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
It happens that this patch causes the generated zoneinfo files to not behave correctly wrt daylight saving time on 32-bit machines. On 64-bit machines or before this patch one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 13:30:00 PDT 2006
With this patch on 32-bit machines, one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 12:30:00 PST 2006
As you can see the daylight saving time is not applied.
What happens with TZ=PST8PDT?
I don't know if it is a problem in zic or a problem on the GNU libc which doesn't correctly interpret the file. This is reproducible with GNU libc from git as the date of today.
What happens if you remove the PST8PDT link to America/Los_Angeles and use "TZ=PST8PDT"? What happens if you remove a link for some zone east of Greenwich and try *that* zone's POSIX specification?

On 2016-03-02 16:59, Guy Harris wrote:
On Mar 2, 2016, at 2:41 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
It happens that this patch causes the generated zoneinfo files to not behave correctly wrt daylight saving time on 32-bit machines. On 64-bit machines or before this patch one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 13:30:00 PDT 2006
With this patch on 32-bit machines, one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 12:30:00 PST 2006
As you can see the daylight saving time is not applied.
What happens with TZ=PST8PDT?
This works as expected.
I don't know if it is a problem in zic or a problem on the GNU libc which doesn't correctly interpret the file. This is reproducible with GNU libc from git as the date of today.
What happens if you remove the PST8PDT link to America/Los_Angeles and use "TZ=PST8PDT"?
It doesn't seems that PST8PDT is a link to America/Los_Angeles, here it is is a different file. That said after removing the file using TZ=PST8PDT starts to show the same issue as with PST+8PDT, that is: $ TZ=PST8PDT date --date=@1152995400 Sat Jul 15 12:30:00 PST 2006
What happens if you remove a link for some zone east of Greenwich and try *that* zone's POSIX specification?
I am not really sure what you mean here. Something like removing the MET file and trying to use for example the MET-1METDST timezone? In that case I get the correct output with and without the file: $ TZ=MET-1METDST date --date=@1152995400 Sat Jul 15 22:30:00 METDST 2006 Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net

On Mar 3, 2016, at 7:56 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
On 2016-03-02 16:59, Guy Harris wrote:
On Mar 2, 2016, at 2:41 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
It happens that this patch causes the generated zoneinfo files to not behave correctly wrt daylight saving time on 32-bit machines. On 64-bit machines or before this patch one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 13:30:00 PDT 2006
With this patch on 32-bit machines, one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 12:30:00 PST 2006
As you can see the daylight saving time is not applied.
What happens with TZ=PST8PDT?
This works as expected.
...because it finds a tzdb file named "PST8PDT".
I don't know if it is a problem in zic or a problem on the GNU libc which doesn't correctly interpret the file. This is reproducible with GNU libc from git as the date of today.
What happens if you remove the PST8PDT link to America/Los_Angeles and use "TZ=PST8PDT"?
It doesn't seems that PST8PDT is a link to America/Los_Angeles, here it is is a different file. That said after removing the file using TZ=PST8PDT starts to show the same issue as with PST+8PDT, that is:
$ TZ=PST8PDT date --date=@1152995400 Sat Jul 15 12:30:00 PST 2006
As I expected.
What happens if you remove a link for some zone east of Greenwich and try *that* zone's POSIX specification?
I am not really sure what you mean here. Something like removing the MET file and trying to use for example the MET-1METDST timezone?
Yes, that's what I meant, if "the MET file" is a file whose name is "MET-1METDST".
In that case I get the correct output with and without the file:
$ TZ=MET-1METDST date --date=@1152995400 Sat Jul 15 22:30:00 METDST 2006
So you removed a time zone file named "MET-1METDST" and then ran that date command, and it reported a time in DST?

On 2016-03-03 11:59, Guy Harris wrote:
On Mar 3, 2016, at 7:56 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
On 2016-03-02 16:59, Guy Harris wrote:
What happens with TZ=PST8PDT?
This works as expected.
...because it finds a tzdb file named "PST8PDT".
Correct, strace confirms that.
What happens if you remove the PST8PDT link to America/Los_Angeles and use "TZ=PST8PDT"?
It doesn't seems that PST8PDT is a link to America/Los_Angeles, here it is is a different file. That said after removing the file using TZ=PST8PDT starts to show the same issue as with PST+8PDT, that is:
$ TZ=PST8PDT date --date=@1152995400 Sat Jul 15 12:30:00 PST 2006
As I expected.
In that case strace tells the posixrules file is opened instead.
What happens if you remove a link for some zone east of Greenwich and try *that* zone's POSIX specification?
I am not really sure what you mean here. Something like removing the MET file and trying to use for example the MET-1METDST timezone?
Yes, that's what I meant, if "the MET file" is a file whose name is "MET-1METDST".
In that case I get the correct output with and without the file:
$ TZ=MET-1METDST date --date=@1152995400 Sat Jul 15 22:30:00 METDST 2006
So you removed a time zone file named "MET-1METDST" and then ran that date command, and it reported a time in DST?
No, I removed the MET file, as the MET-1METDST doesn't exist. Actually I haven't found a zone with DST whose name matches a POSIX specification and that is east of Greenwich. Do you have an example about a zone I should try? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net

On Wed, 2 Mar 2016 23:41:22 +0100 Aurelien Jarno wrote:
It happens that this patch causes the generated zoneinfo files to not behave correctly wrt daylight saving time on 32-bit machines. On 64-bit machines or before this patch one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 13:30:00 PDT 2006
With this patch on 32-bit machines, one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 12:30:00 PST 2006
As you can see the daylight saving time is not applied.
I reproduced this problem on Fedora 23 x86 with glibc 2.22-11.fc23, by building tzcode as follows: $ make clean $ make CFLAGS='-m32' DATEOBJS=date.o date $ TZ=PST+8PDT ./date -r 1152995400 +'%Y-%m-%d %H:%M:%S %z %Z' 2006-07-15 12:30:00 -0800 PST However, if I use GNU glibc built from git (sourceware.org commit 4e940b2f4b577f3a530e0580373f7c2d569f4d63, configured with '../glibc/configure CC=gcc -m32 --build=i486-pc-linux-gnu --prefix=/tmp/prefix') the problem goes away: $ make clean $ make CFLAGS='-m32 -Wl,--rpath=/tmp/prefix/lib -Wl,--dynamic-linker=/tmp/prefix/lib/ld-linux.so.2' DATEOBJS=date.o date $ TZ=PST+8PDT ./date -r 1152995400 +'%Y-%m-%d %H:%M:%S %z %Z' 2006-07-15 13:30:00 -0700 PDT
This is reproducible with GNU libc from git as the date of today.
Which glibc commit were you using? Does it contain any patches compared to upstream glibc? I assume your commit contain the fix for glibc bug 19253. This was fixed in commit c83196b0df4340209f260ffaf90e787c711c268e in November. This issue seems to be on point. See: https://sourceware.org/bugzilla/show_bug.cgi?id=19253 Does the problem go away if you revert commit c83196b0df4340209f260ffaf90e787c711c268e?

On 2016-03-06 16:24, Paul Eggert wrote:
On Wed, 2 Mar 2016 23:41:22 +0100 Aurelien Jarno wrote:
It happens that this patch causes the generated zoneinfo files to not behave correctly wrt daylight saving time on 32-bit machines. On 64-bit machines or before this patch one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 13:30:00 PDT 2006
With this patch on 32-bit machines, one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 12:30:00 PST 2006
As you can see the daylight saving time is not applied.
I reproduced this problem on Fedora 23 x86 with glibc 2.22-11.fc23, by building tzcode as follows:
$ make clean $ make CFLAGS='-m32' DATEOBJS=date.o date $ TZ=PST+8PDT ./date -r 1152995400 +'%Y-%m-%d %H:%M:%S %z %Z' 2006-07-15 12:30:00 -0800 PST
However, if I use GNU glibc built from git (sourceware.org commit 4e940b2f4b577f3a530e0580373f7c2d569f4d63, configured with '../glibc/configure CC=gcc -m32 --build=i486-pc-linux-gnu --prefix=/tmp/prefix') the problem goes away:
$ make clean $ make CFLAGS='-m32 -Wl,--rpath=/tmp/prefix/lib -Wl,--dynamic-linker=/tmp/prefix/lib/ld-linux.so.2' DATEOBJS=date.o date $ TZ=PST+8PDT ./date -r 1152995400 +'%Y-%m-%d %H:%M:%S %z %Z' 2006-07-15 13:30:00 -0700 PDT
Are you sure you have the posixrules file installed in /tmp/prefix/zoneinfo/posixrules? I don't observe the problem on my system when posixrules is not installed.
This is reproducible with GNU libc from git as the date of today.
Which glibc commit were you using? Does it contain any patches compared to upstream glibc?
I have just redone a test just now, I still have an issue with upstream commit 9ff72da471a509a8c19791efe469f47fa6977410. This is without any additional patch.
I assume your commit contain the fix for glibc bug 19253. This was fixed in commit c83196b0df4340209f260ffaf90e787c711c268e in November. This issue seems to be on point. See:
https://sourceware.org/bugzilla/show_bug.cgi?id=19253
Does the problem go away if you revert commit c83196b0df4340209f260ffaf90e787c711c268e?
Reverting this commit doesn't change anything. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net

Aurelien Jarno wrote:
Are you sure you have the posixrules file installed in /tmp/prefix/zoneinfo/posixrules?
No, I didn't have those installed, because glibc 'make install' doesn't install them. Your hint let me figure out what I needed to do to reproduce the problem. I eventually tracked this down to a bug in glibc, which Sébastien Brissaud reported on February 27. See: https://sourceware.org/bugzilla/show_bug.cgi?id=19738 The bug is that glibc adds the posixrules file's first transition time (the minimum time_t value -2147483648) to the UTC offset -28800, and this addition overflows and wraps around to a large positive number. I proposed a glibc patch here: https://sourceware.org/bugzilla/attachment.cgi?id=9074 I don't see a good zic workaround for this glibc bug. zic could emit a slightly later transition time (a day later, say), but this would cause programs to mishandle time stamps near the origin at 1901-12-13.

On 2016-03-08 01:54, Paul Eggert wrote:
Aurelien Jarno wrote:
Are you sure you have the posixrules file installed in /tmp/prefix/zoneinfo/posixrules?
No, I didn't have those installed, because glibc 'make install' doesn't install them. Your hint let me figure out what I needed to do to reproduce the problem.
I eventually tracked this down to a bug in glibc, which Sébastien Brissaud reported on February 27. See:
https://sourceware.org/bugzilla/show_bug.cgi?id=19738
The bug is that glibc adds the posixrules file's first transition time (the minimum time_t value -2147483648) to the UTC offset -28800, and this addition overflows and wraps around to a large positive number.
Thanks a lot for finding that.
I proposed a glibc patch here:
https://sourceware.org/bugzilla/attachment.cgi?id=9074
I don't see a good zic workaround for this glibc bug. zic could emit a slightly later transition time (a day later, say), but this would cause programs to mishandle time stamps near the origin at 1901-12-13.
And thanks for the patch. I have subscribed to the bug, so I can track the review progress. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
participants (7)
-
Arthur David Olson
-
Aurelien Jarno
-
Brian Inglis
-
Guy Harris
-
Ian Abbott
-
Paul Eggert
-
Random832