[Scheme-reports] Date/time package John Cowan (10 May 2012 16:56 UTC)
Re: Date/time package Arthur A. Gleckler (10 May 2012 17:09 UTC)
Re: [Scheme-reports] Date/time package Peter Bex (10 May 2012 18:54 UTC)
Re: [Scheme-reports] Date/time package John Cowan (10 May 2012 21:07 UTC)
Re: [Scheme-reports] Date/time package Peter Bex (10 May 2012 21:58 UTC)
Re: [Scheme-reports] Date/time package Alan Watson (10 May 2012 22:07 UTC)
Re: [Scheme-reports] Date/time package Noah Lavine (10 May 2012 22:41 UTC)
Re: [Scheme-reports] Date/time package John Cowan (11 May 2012 02:43 UTC)
Re: [Scheme-reports] Date/time package John Cowan (11 May 2012 02:16 UTC)
Re: [Scheme-reports] Date/time package Peter Bex (11 May 2012 10:05 UTC)
Re: [Scheme-reports] Date/time package Peter Bex (11 May 2012 10:13 UTC)
Re: [Scheme-reports] Date/time package John Cowan (11 May 2012 14:35 UTC)
Re: [Scheme-reports] Date/time package John J Foerch (10 May 2012 23:40 UTC)
Re: [Scheme-reports] Date/time package John Cowan (11 May 2012 03:01 UTC)
Re: [Scheme-reports] Date/time package John J Foerch (11 May 2012 04:37 UTC)
Re: [Scheme-reports] Date/time package John Cowan (11 May 2012 04:44 UTC)
Re: [Scheme-reports] Date/time package John J Foerch (11 May 2012 05:25 UTC)
Re: [Scheme-reports] Date/time package Daniel Villeneuve (11 May 2012 03:35 UTC)

Re: [Scheme-reports] Date/time package Daniel Villeneuve 11 May 2012 03:33 UTC

On 10/05/12 12:55 PM, John Cowan wrote:
> Peter Bex scripsit:
>
>> I think a comfortable, complete date/time-manipulation is one thing that
>> Scheme is sorely lacking.  We have SRFI-19, but it is a bit unwieldy and
>> not very complete.
> I have written up a proposal for WG2 which can be found at
> http://trac.sacrideo.us/wg/wiki/TimeAdvancedCowan , with a supplement
> on durations and intervals at http://trac.sacrideo.us/wg/wiki/TimePeriodsCowan .
> It's based loosely on the Java package JodaTime, but adapted to the nature
> of a dynamically typed language.  It is certainly comprehensive; how
> comfortable it is, is for others to judge.
>
> If anyone's interested, please take a look and comment here.
>
Because I mentioned in a previous post that we are working a lot with
dates and times in our applications, here are some details.

Dates are first-class objects, with a separate predicate: date?, and a
constructor: (make-date y m d).  Getters produce year, month and day
from a given date.  At the lexical level, a sequence of characters of
the form DDDD-DD-DD is auto-quoted as a date object.

There is a (date->number date) which returns the Modified Julian Day
(MJD) number of that date, and a corresponding (number->date mjd) which
returns a date from an exact integer interpreted as a MJD number.  We're
doing scheduling for today's people, so we do not care much about dates
too far in the past (say, around or prior to the date of adoption of the
Gregorian calendar).

Since we rarely manipulate times in seconds, we use HH:MM to specify
time moments, and ±HHHhMM to specify durations, which are recognized
lexically and auto-quoted/converted as a number of minutes.

Given MJDs and minutes, we usually form "date-time" integers from the
simple ((* 1440 mjd) minutes) formula, which is correct when working
with UTC (GMT) values.

When needing to use local time zones, information from the time zone
(DST start/end, offsets) is passed to conversion functions along with
the date-time to process.

The main goal here is efficiency and control.  Admittedly, this is more
tailored to our intensive and specific use of dates and times than one
would expect from a general purpose date and time library.
--
Daniel Villeneuve
AD OPT, a Kronos Division

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports