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

There are several incompatibilities between my time/date structure and
the Java Date/Calendar/DateFormat object. At least:

SRFI-19 time has nanosecond precision and variable resolution; Java Date
has millisecond precision and resolution.
SRFI-19 time stores leap seconds in the 'nanosecond' field; Java Date in
the second field.
SRFI-19 does time arithmetic on time; Java on Calendars.
SRFI-19 has the Date fields invariant (like a DateFormat, really).
Neither Java Dates nor Calendar fields are invariant.
SRFI-19 requires support of TAI, UTC, process times, and durations,
using the same structure. Java Dates are UTC only.
SRFI-19 defines time zones just as an offset. Java TimeZone and
SimpleTimeZone go a bit further. (I don't mind the TimeZone object; but
I don't plan to add it to SRFI-19. If someone wants to write a timezone
SRFI, they are welcome to. I just don't see the importance).


> -----Original Message-----
> From: bothner@xxxxxxxxxxx [mailto:bothner@xxxxxxxxxxx]On Behalf Of Per
> Bothner
> Sent: Tuesday, June 13, 2000 5:00 PM
> To: Will Fitzgerald
> Cc: Srfi-19@Srfi. Schemers. Org
> Subject: 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
> http://www.javasoft.com/products/jdk/1.2/docs/api/java/util/pa
	--Per Bothner
per@xxxxxxxxxxx   http://www.bothner.com/~per/