[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Note #3: The basic representation of dates

This page is part of the web mail archives of SRFI 19 from before July 7th, 2015. The new archives for SRFI 19 contain all messages, not just those from before July 7th, 2015.

"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
	--Per Bothner
per@xxxxxxxxxxx   http://www.bothner.com/~per/