Posix is pretty much useless for handling timezones correctly; behavior varies
greatly based on the OS, and I am fairly sure the direction of the wind plays a
part as well.
Jim
On Sep 29, 2013, at 12:28, Andy Bennett andy...@ashurst.eu.org wrote:
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
--
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
