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.
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: year (integer) month (integer, 1-12) Day (integer 1-31), Hour (integer 0-23), Minute (integer 0-59), Second (integer 0-59), nanosecond (integer 0-999,999,999 for non-leap seconds; 0-1,999,999,999 for leap seconds). Time zone (integer number of seconds east of Greenwich). 'Time arithmetic' procedures are defined for time objects, not date objects. The fields of a date object are immutable. The following procedures are required (in addition to the conversion procedures mentioned in Note 1): - Date creation procedures (including copying, converting between time zones), - Date formatting procedures, providing both standard ISO Standard 8601 support (without going overboard here), and general formatting operators (like SCSH and C strftime, etc.) - Date reading procedures from ISO Standard strings (again, without going overboard). - date-month-day, date-year-day, etc. (i.e., 'virtual' field accessors). - leap-year? Some justifications. Not including redundant fields in date structure: they're easy to compute. 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. Also, trying to figure out whether the Kurds are observing DST in violation of official Iraqi policy is more than I want to manage. Time arithmetic on time, not dates. Simpler, for sure. Dates are just 'views' on time, not time points themselves. Immutable fields: Dates are just 'views' on time, not time points themselves. -- Will