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