[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
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.
AD OPT, a Kronos Division
Scheme-reports mailing list