This page is part of the web mail archives of SRFI 19 from before July 7th, 2015. The new archives for SRFI 19 contain all messages, not just those from before July 7th, 2015.
I started coding up the proposed revisions to my draft. This resulted in more revisions. Now, there are only two time-related data types: a 'time' object, and seconds (as in SRFI 18). The time object has the following components: (time-second time) => real (0 to 61.0) potentially includes leap seconds (time-minute time) => integer (0 to 59) (time-hour time) => integer (0 to 23) (time-day time) => integer (1 to 31) (time-month time) => integer (1 to 12) (January=1, etc.) (time-year time) => integer (time-zone-offset time) => integer (the number of seconds east of GMT for this timezone) Implementations can vary as to whether leap seconds are included. Range is implementation specific. The 'second' object is a real, potentially inexact, corresponding to the number of seconds from 0 to implementation specific upper range, with the meaning of 0 implementation specific. ;; get the current values (current-time) (current-seconds) ;; creator (make-time second minute hour date month year zone-offset) ;; other readers (time-year-day time) => integer. Day of year (0=1/1 , etc.) (time-week-day time) => integer. Day of week (0=Sunday, etc.) (julian-day time) => real returns the Julian day, where JD 0 JD 0 designates the 24 hours from noon UTC on 1 January 4713 BC to noon UTC on 2 January 4713 BC. (modified-julian-day time) => real. Returns the modified Julian day; number of days since 17 Nov 1858 at 00:00:00 UTC. ;; writers (set-time-second! time real) (set-time-minute! time integer) (set-time-hour! time integer) (set-time-day! time integer) (set-time-month! time integer) (set-time-year! time integer) (set-time-zone-offset! time integer) ;; converters. all strings are ISO formats. (copy-time time) => time (time->seconds time) => real (seconds->time real) => time (julian-day->time real) => time (modified-julian-day->time real) => time (time->universal-time! time) => time (side-effects); converts to GMT (time->universal-time time) => time (copies) (time->string time . include-time-zone-offset?) => string (time->date-string time) => string e.g., 2000-01-31 (time->hour-string time) => string e.g. 12:34:56.789 (string->time string) => time ;; comparing procedures The comparison procedures must take the time-zone-offset into consideration. (time=? time1 time2) => boolean (time>? time1 time2) => boolean (time<? time1 time2) => boolean (time>=? time1 time2) => boolean (time<=? time1 time2) => boolean ;; data type probes (time? time) => boolean ;; time arithmetic (add-seconds! time real) => time adds number of seconds to date, side-effecting it (add-seconds time real) => time adds number of seconds to date, creating new date. Here's a summary of the changes: I dropped the 'machine time' procedures. They didn't fit very well in the overall scheme. I dropped the daylights savings time flag. I had thought this typically changed the semantics of a time object for time arithmetic, but this doesn't seem to be the case (at least for MzScheme). Besides, it's not always very usefully defined. If (current-time) needs to adjust for daylights savings time, this should be reflected in the time-zone-offset. I dropped the special 'Julian day' time object, and just made them readers on the time object. I added the 'modified Julian day' reader, which provides lower numbers (and starts at midnight). I added the time->universal-time! and time->universal-time, which takes a time object, and converts it to a 0 time-zone-offset. I added the add-seconds! and add-seconds procedures. These are procedures that allow you to add an arbitrary number of seconds to a time object. (Marc, this means your threads could run until you ran out of integers -- they might even stop using Cobol by then!). In the code I've written so far, I think all the right things happen at the time boundaries. Leap seconds are still a pain, though. I added a couple of additional string output procedures, to get just the date or the hour. I'll post the code soon. Currently, the only system dependencies are on CURRENT-SECONDS, knowing the time object corresponding to (seconds->date 0) at GMT, and probing the local time-zone-offset. I'll also begin revising the proposal in earnest.