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 http://www.javasoft.com/products/jdk/1.2/docs/api/java/util/package-summary.html -- --Per Bothner per@xxxxxxxxxxx http://www.bothner.com/~per/