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

--
Will

> -----Original Message-----
> From: xxxxxx@bothner.com [mailto:xxxxxx@bothner.com]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" <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/pa
ckage-summary.html
--
	--Per Bothner
xxxxxx@bothner.com   http://www.bothner.com/~per/