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
invalid.

Cheers,
Peter
--
http://sjamaan.ath.cx
--
"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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports