Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 18 Jan 2018 11:34:52 -0500
From: Rich Felker <>
Subject: Re: Differences between strftime in musl and glibc

On Thu, Jan 18, 2018 at 04:25:07PM +0000, Adrián López Tejedor wrote:
> Hi,
> I was having a problem parsing dates with python in an Alpine container and
> after some time digging I have found a difference in how musl and
> glibc calculate the unix Epoch using strftime.
> The format specifier to get the unix epoch is "%s", which is an extension
> of GNU (
> ).
> In Glibc they use mktime (
>, being
> this function aware of time zone.
> In musl is calculated without mktime, adding the seconds of each part of
> the tm struct (
> and substracting the GMT offset. This method is unaware of the TZ data (I
> have not seen how to define that gmt offset when using strptime).
> Calling directly to musl/mktime work as expected.
> I have attached a small program which shows the difference between musl and
> glibc.
> Compiled with glibc:
> $ TZ=Europe/Madrid ./a.out
> strftime: -3600
> mktime: -3600
> $ TZ=America/New_York ./a.out
> strftime: 18000
> mktime: 18000
> Compiled with musl:
> $ TZ=Europe/Madrid ./a.out
> strftime: 0
> mktime: -3600
> $ TZ=America/New_York ./a.out
> strftime: 0
> mktime: 18000
> Thanks!
> Adrián

> #define _XOPEN_SOURCE
> #include "stdio.h"
> #include "stdlib.h"
> #include "time.h"
> #include "string.h"
> int main(void) {
>   char buf[100];
>   struct tm tm1, tm2;
>   memset(&tm1, 0, sizeof(struct tm));
>   memset(&tm2, 0, sizeof(struct tm));
>   strptime("1/1/1970 00:00:00", "%d/%m/%Y %H:%M:%S", &tm1);
>   strptime("1/1/1970 00:00:00", "%d/%m/%Y %H:%M:%S", &tm2);
>   strftime(buf, 100, "%s", &tm1);
>   printf("strftime: %s\n", buf);
>   time_t seg = mktime(&tm2);
>   printf("mktime: %ld\n", seg);
>   return 0;
> }

The glibc behavior assumes the tm object is in units of local time (in
the current time zone), which is a really bad assumption, since
everything else about the strftime API is timezone-agnostic and works
with tm objects produced by gmtime() as well as local times. So I
believe the musl behavior is correct and the glibc behavior is wrong,
but I'm open to further discussion. It probably needs to happen on the
Austin Group tracker/list, as %s is scheduled for inclusion in future
versions of POSIX but grossly underspecified:

In particular, the glibc behavior requires that strftime become aware
of [changes in] the timezone, which it's currently not specified to
do, and there's no specification of if or how strftime determines if
the argument is a local or UTC time.

My preference would be to say that, unless the struct tm was produced
by localtime[_r] or derived from such a struct tm, it's unspecified
what time zone %s is referenced against. But I'm open to discussion as
part of the standardization process.


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.