From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12374 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Adri=C3=A1n_L=C3=B3pez_Tejedor?= Newsgroups: gmane.linux.lib.musl.general Subject: Differences between strftime in musl and glibc Date: Thu, 18 Jan 2018 16:25:07 +0000 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="001a11410358e3ef8f05630f6896" X-Trace: blaine.gmane.org 1516292641 31871 195.159.176.226 (18 Jan 2018 16:24:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 Jan 2018 16:24:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12390-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 18 17:23:57 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ecCyQ-0006bl-P8 for gllmg-musl@m.gmane.org; Thu, 18 Jan 2018 17:23:30 +0100 Original-Received: (qmail 18369 invoked by uid 550); 18 Jan 2018 16:25:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 18328 invoked from network); 18 Jan 2018 16:25:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ZaUZCe51y679HtnZIkDswqK95N9ziLYLqGscIt1MqVk=; b=TIiCDYFwVLm1K640A9tMo/eHDROPrGeQ+HQB8k/4pxodNKnj0pGYaaZhiCvLZM2G4B VxUxUgiSiBXAeVuh48o17m6rZNpd+aR0oAbK7ejFQb6uYioXERziv4whTzdKWxXNTPvT DLelJTx6yFkXMX5o55+dsClc7iL4cKBtMPO16gPYgqZQ0lbDJhWgK9H9OFT7HztRlUDK k+U8qIgOT8yREw+Nxzrm32s6Nt0X/Mzit1dl3jKi60vUwBwCZ8GignzuUdHMcdHEcxgl rsX+Uz0zzjCo2zR0pcX4IyDBzY8Vzix2dA7gtryj3Try+hswv9Q9hJKEnQdLuc5h3pu3 NjQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZaUZCe51y679HtnZIkDswqK95N9ziLYLqGscIt1MqVk=; b=bVvYd5nA5NKS4PuwFyfKI+vp13KI6BvUbzuueUzzFBDMEFJXDNG+whNjhYjkzWdD/U zRkLFPfUPuSJQcOoK8WJWpAhRpQNYAN8C6T9BiBRqIcxiHZI+4uTnGWNfutE9j9rFeRy Y1XcrKlnt1KgJJazqzJb2yRvjCLCCP+cpeh3zOq3+TIANJ1E3DwD5BYqIpA3k3qwLhGW CRQq6jUzdl/LsJ0GrsP0xh7lXI0w2FzYROrsepDneGbk4SUjnDEn58cwDqsRAS3+norK PAzI0/oK7rqgZn1IJytAnNwR7i/m7MISJotsXkDlqQwQKnDMKkgL8g9RqWyJE/SnV+sk N/Ug== X-Gm-Message-State: AKwxytcEqO8nrZaHH699BSDcEOVub2OrR62M9wv8cnoGYYihBHOb9uNl UzuVkNOFoFso65Ve9RAdkxOkCIzocl6qf+7mrFtUlg== X-Google-Smtp-Source: ACJfBov3DotWa2+I1IljencUMF3eCg5JGJDndfNn+TOf+e3sErnHUu2xFpkSKsOrymvPm9pUo0YZ4iq8bpMQL0oEQ7M= X-Received: by 10.25.33.70 with SMTP id h67mr10173663lfh.128.1516292718973; Thu, 18 Jan 2018 08:25:18 -0800 (PST) Xref: news.gmane.org gmane.linux.lib.musl.general:12374 Archived-At: --001a11410358e3ef8f05630f6896 Content-Type: multipart/alternative; boundary="001a11410358e3ef8b05630f6894" --001a11410358e3ef8b05630f6894 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 ( https://www.gnu.org/software/libc/manual/html_node/Formatting-Calendar-Time= .html ). In Glibc they use mktime ( https://github.com/bminor/glibc/blob/master/time/strftime_l.c#L1127), being this function aware of time zone. In musl is calculated without mktime, adding the seconds of each part of the tm struct ( https://git.musl-libc.org/cgit/musl/tree/src/time/strftime.c?h=3Dv1.1.18#n1= 32) 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=3DEurope/Madrid ./a.out strftime: -3600 mktime: -3600 $ TZ=3DAmerica/New_York ./a.out strftime: 18000 mktime: 18000 Compiled with musl: $ TZ=3DEurope/Madrid ./a.out strftime: 0 mktime: -3600 $ TZ=3DAmerica/New_York ./a.out strftime: 0 mktime: 18000 Thanks! Adri=C3=A1n --001a11410358e3ef8b05630f6894 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I was having a problem parsing date= s with python in an Alpine container and after some time digging I have fou= nd a difference in how musl and glibc=C2=A0calculate the unix Epoch using s= trftime.

The format specifier to get the unix=C2= =A0epoch is "%s", which is an extension of GNU (https://www.gnu.org/software/libc/manual/html_node/Formatting-Calendar-Tim= e.html).

In Glibc they use mktime (https:= //github.com/bminor/glibc/blob/master/time/strftime_l.c#L1127), being t= his function aware of time zone.

In musl=C2=A0is c= alculated without mktime, adding the seconds of each part of the tm struct = (https://git.musl-libc.org/cgit/musl/tree/src/time/strftime= .c?h=3Dv1.1.18#n132) and substracting the GMT offset. This method is un= aware of the TZ data (I have not seen how to define that gmt offset when us= ing strptime).

Calling directly to musl/mktime wor= k as expected.

I have attached a small program whi= ch shows the difference between musl and glibc.

Compiled with=C2=A0glibc:
$ TZ=3DEurope/Madrid ./a.out=
strftime: -3600
mktime: -3600
$ TZ=3DAmerica= /New_York ./a.out
strftime: 18000
mktime: 18000


Compiled with=C2=A0musl:
$ TZ=3DEurope/Madrid ./a.out=C2=A0=C2=A0
strftime: 0
=
mktime: -3600
$ TZ=3DAmerica/New_York ./a.out
strf= time: 0
mktime: 18000


Thanks!
Adri=C3=A1n
--001a11410358e3ef8b05630f6894-- --001a11410358e3ef8f05630f6896 Content-Type: text/x-csrc; charset="US-ASCII"; name="date_musl_glibc.c" Content-Disposition: attachment; filename="date_musl_glibc.c" Content-Transfer-Encoding: base64 Content-ID: <1610a0d136c81a430cd1> X-Attachment-Id: 1610a0d136c81a430cd1 I2RlZmluZSBfWE9QRU5fU09VUkNFCiNpbmNsdWRlICJzdGRpby5oIgojaW5jbHVkZSAic3RkbGli LmgiCiNpbmNsdWRlICJ0aW1lLmgiCiNpbmNsdWRlICJzdHJpbmcuaCIKCgppbnQgbWFpbih2b2lk KSB7CiAgY2hhciBidWZbMTAwXTsKICBzdHJ1Y3QgdG0gdG0xLCB0bTI7CiAgbWVtc2V0KCZ0bTEs IDAsIHNpemVvZihzdHJ1Y3QgdG0pKTsKICBtZW1zZXQoJnRtMiwgMCwgc2l6ZW9mKHN0cnVjdCB0 bSkpOwogIHN0cnB0aW1lKCIxLzEvMTk3MCAwMDowMDowMCIsICIlZC8lbS8lWSAlSDolTTolUyIs ICZ0bTEpOwogIHN0cnB0aW1lKCIxLzEvMTk3MCAwMDowMDowMCIsICIlZC8lbS8lWSAlSDolTTol UyIsICZ0bTIpOwoKICBzdHJmdGltZShidWYsIDEwMCwgIiVzIiwgJnRtMSk7CiAgcHJpbnRmKCJz dHJmdGltZTogJXNcbiIsIGJ1Zik7CgogIHRpbWVfdCBzZWcgPSBta3RpbWUoJnRtMik7CiAgcHJp bnRmKCJta3RpbWU6ICVsZFxuIiwgc2VnKTsKCiAgcmV0dXJuIDA7Cn0K --001a11410358e3ef8f05630f6896--