This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH][BZ #926] Mention timezone for strftime %s
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 12 Oct 2013 20:42:58 +0200
- Subject: Re: [PATCH][BZ #926] Mention timezone for strftime %s
- Authentication-results: sourceware.org; auth=none
- References: <20131012165835 dot GA26247 at domone dot podge> <20131012170354 dot GU20515 at brightrain dot aerifal dot cx>
On Sat, Oct 12, 2013 at 01:03:54PM -0400, Rich Felker wrote:
> On Sat, Oct 12, 2013 at 06:58:35PM +0200, OndÅej BÃlka wrote:
> > Hi,
> > this is next bug that received no response. Patch is following, take it
> > or close bug I am sligthly for adding it.
> > * manual/time.texi (strftime): Mention that %s uses current
> > timezone.
> > diff --git a/manual/time.texi b/manual/time.texi
> > index ff31e28..33a55ef 100644
> > --- a/manual/time.texi
> > +++ b/manual/time.texi
> > @@ -1277,6 +1277,7 @@ but was previously available as a GNU extension.
> > @item %s
> > The number of seconds since the epoch, i.e., since 1970-01-01 00:00:00 UTC.
> > Leap seconds are not counted unless leap second support is available.
> > +Note that like mktime, this uses the current time zone instead of tm_gmtoff.
> > This format is a GNU extension.
> It should be noted that %s was proposed and seems to have been
> accepted for inclusion in the next issue of POSIX, but that this issue
> (which offset it uses, or whether it even uses an offset at all) is
> not clearly specified. I think there should be an effort to coordinate
> this with the Austin Group and either agree on a practice, or agree
> that it's implementation-defined, before documenting a particular
> For what it's worth, I think using the current time zone rather than
> tm_gmtoff is bad behavior since it makes %s unusable with struct tm's
> obtained from gmtime().
A point of bug entry was to warn about this behaviour. It is part of
libc api now and it would be unlikely to change. Keeping timezone
undefined would defeat purpose of standardization.
For saner behaviour posix should add new flag/modifier.