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