[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Note #3: The basic representation of dates
"Will Fitzgerald" <fitzgerald@xxxxxxxxxxxx> 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