chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] Timezone bugs in the posix module


From: Andy Bennett
Subject: [Chicken-users] Timezone bugs in the posix module
Date: Sun, 29 Sep 2013 18:28:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

Hi,

There seem to be some inconsistencies in the timezone handling in the
posix module.


http://api.call-cc.org/doc/library/current-seconds
-----
(current-seconds) procedure

    Returns the number of seconds since midnight, Jan. 1, 1970.
-----

This seems to be true and it appears to be in Zulu time.

On a machine in BST:

-----
$ date; csi -p '(use posix) (current-seconds)'
Sun Sep 29 18:06:50 BST 2013
#<unspecified>
1380474410.0
-----

On a machine in CDT:

-----
$ date; csi -p '(use posix) (current-seconds)'
Sun Sep 29 12:06:50 CDT 2013
#<unspecified>
1380474410.0
-----

...we get the same value. All is well.



However,

http://api.call-cc.org/doc/posix/seconds-%3Estring
-----
(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:

-----
$ date; csi -p '(use posix) (seconds->string 0)'
Sun Sep 29 12:08:15 CDT 2013
#<unspecified>
Wed Dec 31 18:00:00 1969
-----


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
-----


...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
-----


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


...and Europe/London:

-----
$ export TZ=Europe/London; date; csi -p '(use posix) (seconds->string 0)'
Sun Sep 29 18:21:50 BST 2013
#<unspecified>
Thu Jan  1 01:00:00 1970
-----


...and a definitely bogus timezone:

-----
$ 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
-----

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

-----
$ wdate
Sun Sep 29 12:15:19 CDT 2013 (America/Chicago)
Sun Sep 29 17:15:19 UTC 2013 (UTC)
Sun Sep 29 18:15:19 BST 2013 (Europe/London)
Sun Sep 29 19:15:19 CEST 2013 (Europe/Rome)
Mon Sep 30 06:15:19 NZDT 2013 (NZ)
-----




On the machine in BST:

-----
$ 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
-----

-----
$ export TZ=America/Chicago; date; csi -p '(use posix) (seconds->string 0)'
Sun Sep 29 12:11:43 CDT 2013
#<unspecified>
Wed Dec 31 18:00:00 1969
-----

...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).


-----
$ 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

$ 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

$ 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

$ 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
-----






Regards,
@ndy

-- 
address@hidden
http://www.ashurst.eu.org/
0x7EBA75FF




reply via email to

[Prev in Thread] Current Thread [Next in Thread]