On Tue, 23 Nov 2010 16:05 -0500, "John Cowan" <[email protected]> wrote: > Christopher Chittleborough scripsit: > > > (chronology-with-time-zone CHRONOLOGY TIMEZONE) > > Presumably a "time zone name" is a string. Say so explicitly? > > I actually do say what it can be: an offset in minutes from UTC, > a string from the TZ database, or an implementation-defined alternative. Err, you don't use the word "string", only "name". I was thinking of something like: "If the implementation supports the tz database, and timezone is a string equaling a time zone name defined by that database, ..." This allows implementations to accept other strings, which is probably appropriate.
> > > (date->instant DATE) > > What happens if there is not enough info in DATE to uniquely > > determine an instant? Signal an error? Return #f? > > Added "otherwise return #f". That's clearly the Right Thing to do. > > (date-field date FIELDNAME) > > Presumably FIELDNAME can be a symbol. Can it also be a string? > > That would require an extra lookup at run time. I think symbols are > sufficient. Agreed. How about adding "(a symbol)" to the spec? Like this: "Returns the numeric value of the field named fieldname (a symbol) within date ..." > > (date-increment date fieldname increment) <SNIP> > Excellent wording; adopted. > > The 'century' values in the ISO chronology don't seem right. > > If 1965 AD has century=19 in ISO, then 33 AD must have century=0 > > so 43 BC would have century=-1, not 0. > Fixed. So (say) 43 BC is century -1 in Julian, Gregorian and ISO. Interesting. While the Joda Time API looks pretty good on brief reading, the Scheme version is much nicer -- yet another win for procedural APIs over class-based programming. Cheers ... Chris _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
