On Thu, May 10, 2012 at 05:07:05PM -0400, John Cowan wrote:
> 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.

Sure, but there's only one environment in which the program is running,
which means there is always one timezone, and the user will generally
demand applications to behave consistently according to his or her
preferences.

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

Excellent, this seems a good way to express how it should behave without
being too particular about implementation specifics.

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

It just occurred to me that it might be useful if there was a
"current-chronology" that behaves like "current-input-port", which
is then parameterizable (maybe call-with-chronology).

I'm not sure, it might also be overkill since you can't really do
anything special to chronologies except query them.  Just wanted to
put the idea out there to see what others think.

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

Having chronologies not be timezone-dependent (ie, all UTC) seems nice,
but is UTC general enough?
For example, according to this technical note, NASA measures time on
Mars missions with an analogue to UTC called (gee) MTC:
http://www.giss.nasa.gov/tools/mars24/help/notes.html
They do seem to have a way to convert between Earth time (and, hence UTC)
and Martian time, but it's probably more convenient and natural to enter
times directly in "local time".

It's probably sufficient to specify that the base-chronologies are
relative to *some* ("preferred"?) coordinated standard time, and
perhaps note that this is defined as UTC for all the predefined ones.

Non-earth-based chronologies look like an ideal way to test the
generality of the proposal, but it's up to you to determine the
scope of the proposal.  Joda time doesn't seem to deal with these(?)

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

I see how this could be a problem, but in practice libraries often
already contain extensions right in the same module, which might export
extra names.

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

That sounds like a good way to do it if the goal is to be strict in
how libraries can be extended.

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

Agreed.

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

Ah, that could be quite useful actually!  It can be derived from the
text but it's probably good to state this explicitly.

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