[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Note #3: The basic representation of dates
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
> 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
> > 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