[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

more revisions

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


;; 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

(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 

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.