Re: [Chicken-users] Timezone bugs in the posix module

[John Cowan]

Andy Bennett scripsit:

> (seconds->string [SECONDS]) procedure
> 
>     Converts the local time represented in SECONDS into a string of the
> form "Tue May 21 13:46:22 1991". SECONDS defaults to the value of
> (current-seconds).
> -----
> 
> ..seems to be misleading as [SECONDS] is in Zulu time (as shown above).
> It is seconds->string itself which does the conversion to local time for
> the resulting string:

Right.  I have fixed the wiki to say "Converts the time represented in
SECONDS into a local-time string ...".  It's not a very useful procedure
anyway, and only exists because it exposes Posix ctime().  I recommend
using (time->string (seconds->local-time (current-seconds))), provided
you aren't doing this so often that the 10-element vector that gets
allocated and promptly discarded is a problem.

> However, there's also a bug as I get the following on a machine in BST:
> 
> -----
> $ date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 18:09:02 BST 2013
> #<unspecified>
> Thu Jan  1 01:00:00 1970
> -----

That's what you should see: the time of the Epoch in British Summer Time
(UTC+1).

> ...and if I force that machine into BST:
> 
> -----
> $ export TZ=BST; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 17:21:34 BST 2013
> #<unspecified>
> Thu Jan  1 00:00:00 1970

Actually, "BST" is not a valid value of TZ.  When the value is invalid,
the Posix timezone system treats it as equivalent to UTC, which is what
you are getting in both the date command and seconds->string.

> $ export TZ=rubbish; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 17:25:47 rubbish 2013
> #<unspecified>
> Thu Jan  1 00:00:00 1970

Same story here.  Note that the bad TZ value is used as the name printed
by the date command, but the value is UTC.

> ...so seconds->string sometimes ignores the timezone and doesn't throw
> an error.

The fault is in the C library, which has no concept of throwing errors.

> $ export TZ=CDT; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 17:10:58 CDT 2013
> #<unspecified>
> Thu Jan  1 00:00:00 1970

Again, "CDT" is not a valid value of TZ.  "CST6CDT" is valid, and is a
synonym of "America/Chicago".

> ...so it seems that the posix unit does not support the same names for
> timezones as the underlying operating system / date command (Linux in
> this case).

Actually it does, except perhaps in Windows.

> $ export TZ=Europe/Rome; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 19:12:52 CEST 2013
> #<unspecified>
> Thu Jan  1 01:00:00 1970

Valid, UTC+2.

> $ export TZ=CEST; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 17:13:10 CEST 2013
> #<unspecified>
> Thu Jan  1 00:00:00 1970

Invalid, UTC.

> $ export TZ=NZ; date; csi -p '(use posix) (seconds->string 0)'
> Mon Sep 30 06:14:00 NZDT 2013
> #<unspecified>
> Thu Jan  1 12:00:00 1970

Valid, UTC+12.

> $ export TZ=NZDT; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 17:14:15 NZDT 2013
> #<unspecified>
> Thu Jan  1 00:00:00 1970

Invalid, UTC.

A valid TZ value is the pathname of an existing file relative to
/usr/share/zoneinfo.

-- 
A rose by any other name                            John Cowan
may smell as sweet,                                 http://www.ccil.org/~cowan
but if you called it an onion                       address@hidden
you'd get cooks very confused.          --RMS