"Will Fitzgerald" <xxxxxx@neodesic.com> writes:

> Note #3: The basic representation of dates
>
> Dates are representations of time, given the context of both the
> Gregorian calendar and local time zones. (This is what is defined as a
> 'time' in the current version of my SRFI).
>
> It's its own data type, with the following components:
> ...
> Time zone (integer number of seconds east of Greenwich).
> Time zone as seconds: time zone hacking is a complicated thing to do,
> and very non-standard (for example, time zone names are not standard).
>
> Not including daylight savings time flag: DST is subsumed in time zones.

In principle, timezone should be an opaque type.  I think of a 'date'
as a triple of:
(1) a time value,
(2) a timezone, including day light saving
(3) formatting rules:  How to print the date.
(The formatting rules could be a separate object, but since dates are
all about how time instances should be presented in human-reasonable
form, one might as well consider teh formatting part of the date.)

I really don't think we should tie the timezone representation
to an integer.  Why not make it an opaque type, but provide ways
to convert from a timezone to an offset?  (Note the offset depends
on the time, because of daylight savings time.)

I'm of course hoping that srfi-19 will be more-or-less compatible with
the Java casses.  Specifically, I am hoping that I will be able to
represent a "time" as a java.util.Date object and a "date" as a
java.util.Calendar object.   I would dislike having to create a wrapper
class unless there was a really good reason for it.

For the specification of the Java time classes, see
http://www.javasoft.com/products/jdk/1.2/docs/api/java/util/package-summary.html
--
	--Per Bothner
xxxxxx@bothner.com   http://www.bothner.com/~per/