Peter Bex scripsit:

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

That's the idea, yes, but there's a lot of flexibility.  It so happens
that the machine which owns the keyboard I'm using and the one on which
the mail client is running are both on America/New_York, but that isn't
always so.

>    If that remains unspecified, there's no portable way to obtain the
>    user's current timezone.

I've added some general language to that effect.

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

Mm, okay.  I have modified `make-date`, `convert-date`, and `make-duration`.

> - Why are chronologies stored in some static location, which requires
>    access by name?

I have now divided chronologies into _base chronologies_, which
are predefined by the application and still have names, and derived
chronologies, which are created by `make-derived-chronology` (formerly
`chronology-with-time-zone`) and `make-compound-chronology`, and don't.

>    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 trouble is that there is no way to create your own base chronologies,
so there must be a way to discover them.  Having implementations add
random names to a standard library breaks the contract that when you
import a library, you only get the set of names that the standard says
you will get, and all other names remain free.

Allowing the programmer to pass in a symbol, and an error to be signalled
if the symbol is not known, is the simplest way I can think of to arrange
for this.  This will come up in many WG2 libraries that provide a facade
over existing data, notably in UcdCowan.

> It makes more sense to at least allow the programmer to enter constant
> strings in ISO format like "2012-05-10T12:19:30".

That would be the business of a separate formatting library, which I don't
yet have a proposal for.  This is the date-time *arithmetic* library.

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

Yes, I think so.

> 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 each other") or flat out
> invalid.

Mutually inconsistent, yes.

Nothing happens, except that without sufficient information, you can't
resolve the date object to an instant.  For example, (define x
(make-date (chronology 'gregorian) '((era . 1) (century-of-era . 20))))
specifies the whole 20th century, not some particular instant in it,
so (date-field x 'instant) will return #f.

--
John Cowan   <cowan@ccil.org>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher

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