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 [email protected] you'd get cooks very confused. --RMS _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
