From: Paul Eggert <eggert@cs.ucla.edu>
To: DJ Delorie <dj@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [swbz 29035] mktime vs non-DST
Date: Wed, 17 Aug 2022 20:02:35 -0700 [thread overview]
Message-ID: <4e2b42bf-b103-72fc-ab79-5ddfaa8f32da@cs.ucla.edu> (raw)
In-Reply-To: <xnsflu5nyq.fsf@greed.delorie.com>
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
On 8/17/22 18:39, DJ Delorie wrote:
> It does stop mktime from returning -1 in the problem case, but it still
> returns a different value than pre-2.29. Older code returned the
> standard time result, your patches return a DST result, even if the zone
> has no DST.
Actually, the old (glibc 2.28) code could return a standard time result
even in zones with DST, and this led to results that weren't
self-consistent.
For example, suppose we use the attached program to ask mktime "What
time is it in Fiji on July 1 at 00:00 DST for the two years 2029 and
2030?" Although Fiji no longer observes DST (it stopped last year), the
old glibc code does this:
2029-07-31 23:00:00 +1300 +13
2030-08-01 00:00:00 +1300 +13
whereas Gnulib (and glibc with the proposed patches) does this:
2029-07-31 23:00:00 +1300 +13
2030-07-31 23:00:00 +1300 +13
The old code is inconsistent with itself, because it gets confused by
the DST that Fiji stopped observing in in 2021. The new code is
consistent with itself, as well as with similar questions asked about
New York, Los Angeles, etc. when you ask for a DST during a day that DST
is not observed.
There is no perfection in this area because the mktime API is busted
(though POSIX may improve it if they listen to me :-). That being said,
the Gnulib mktime behavior should be better than the old glibc behavior
for the great majority of users.
[-- Attachment #2: uu.c --]
[-- Type: text/x-csrc, Size: 497 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
void
check_year (int year)
{
struct tm tm;
tm.tm_year = year - 1900;
tm.tm_mon = 7;
tm.tm_mday = 1;
tm.tm_hour = tm.tm_min = tm.tm_sec = 0;
tm.tm_isdst = 1;
time_t t = mktime (&tm);
if (t != (time_t) -1)
{
char buf[1000];
strftime (buf, sizeof buf, "%Y-%m-%d %H:%M:%S %z %Z", &tm);
puts (buf);
}
}
int
main (void)
{
setenv ("TZ", "Pacific/Apia", 1);
check_year (2029);
check_year (2030);
}
next prev parent reply other threads:[~2022-08-18 3:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-17 21:18 DJ Delorie
2022-08-17 21:50 ` Carlos O'Donell
2022-08-17 23:10 ` Paul Eggert
2022-08-18 1:39 ` DJ Delorie
2022-08-18 2:37 ` Carlos O'Donell
2022-08-18 3:16 ` Paul Eggert
2022-08-18 4:05 ` Carlos O'Donell
2022-08-18 21:17 ` DJ Delorie
2022-08-18 21:57 ` Paul Eggert
2022-08-18 22:40 ` DJ Delorie
2022-08-18 22:58 ` Paul Eggert
2022-08-19 18:15 ` DJ Delorie
2022-08-19 22:04 ` Paul Eggert
2022-08-18 3:02 ` Paul Eggert [this message]
2022-09-08 20:25 ` DJ Delorie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4e2b42bf-b103-72fc-ab79-5ddfaa8f32da@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=dj@redhat.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).