[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Date/time package
On Thu, May 10, 2012 at 12:55:38PM -0400, John Cowan wrote:
> 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.
Looks interesting indeed.
A few comments about TimeAdvancedCowan proposal:
- The chronology stuff looks awkward to use. Especially the
default-chronology is so ill-specified it's more or less useless.
If it's supposed to represent the current machine time + zone,
that makes sense but please say so, so that people can rely on that.
If that remains unspecified, there's no portable way to obtain the
user's current timezone.
- If default-chronology is a useful value, why not make it the default
if not specified with make-duration and make-date? Since we now
have case-lambda, having an optional initial argument isn't that
hard to do either anymore.
- Why are chronologies stored in some static location, which requires
access by name? This means they can't be GCed (memory leak!) and
requires people to invent arbitrary names. When chronologies are
created in modules, can they clash? It's more Schemely to have
chronologies be first-class objects and define a couple of default
names (iso, gregorian julian and tai) that *must* be exported by
the datetime module. The user can use the standard definition forms
Scheme offers to declare their named chronology objects. It's also
less verbose if short names are used. The user can always prefix
chronologies at will using the "import" form.
> > (How, for example, do you convert a given time in a
> > zone to another zone? How do you go back a month? etc)
> (define iso (chronology 'iso))
> (define new-york-zone
> (chronology-with-time-zone 'America/New_York iso "America/New_York"))
> (define dutch-zone
> (chronology-with-time-zone 'Europe/Amsterdam iso "Europe/Amsterdam"))
> (define new-york-moment (make-date new-york-zone
> '((year . 2012) (month-of-year . 5) (day-of-month . 10)
> (hour-of-day . 12) (minute-of-hour . 19) (second-of-minute . 30))))
That's awfully verbose! The signal-to-noise ration is quite low here.
It makes more sense to at least allow the programmer to enter constant
strings in ISO format like "2012-05-10T12:19:30".
However, that's a can of worms too since ISO format seems quite tied
to the "iso" chronology... hm, maybe input formats can be linked to
chronologies.... However, we wouldn't want to add fully localized
strings. I think that's actually one of the problems with SRFI-19, that
it tried to do too much there, and the reason the srfi-19 egg in Chicken
is such a sprawling mess of code. So until this can be resolved I'm
afraid the alist is the best we can do.
By the way, what happens when one of these fields is omitted? The text
only says an error must be raised if the fields are _inconsistent_ (which
I take to mean "inconsistent with respect to eachother") or flat out
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
Scheme-reports mailing list