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

Re: [Scheme-reports] Date/time package



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@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports