Re: [Chicken-users] Timezone bugs in the posix module
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
Re: [Chicken-users] Timezone bugs in the posix module
Jim Ursetto scripsit: 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. Actually, there are only two systems in live use, IANA (formerly Olson) and Windows (excluding Cygwin). What I said in my previous post referred to the IANA system, which is used on all the Chicken platforms other than MinGW. -- Eric Raymond is the Margaret Mead John Cowan of the Open Source movement.co...@ccil.org --Bruce Perens, http://www.ccil.org/~cowan some years ago ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Timezone bugs in the posix module
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 nameJohn Cowan may smell as sweet, http://www.ccil.org/~cowan but if you called it an onion co...@ccil.org you'd get cooks very confused. --RMS ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
