PARSE-TIMESTRING works fine, but we need a more human-friendly parser that can handle stuff like “08/03/2006 1:54pm CST”. or maybe not? see http://chaitanyagupta.com/lisp/chronicity/
Also, the time functions in the venerable and honored clsql library. This may be a tall order.
Integrate local-time with http://common-lisp.net/project/cl-l10n/
Also drop time/timezone related functionality from cl-l10n.
http://www.twinsun.com/tz/tz-link.htm Right now, we’re using zic compiled files, which have a limited scope. They may also be larger than the corresponding rule files.
Many of the operations currently defined on timestamps should not really be defined on timestamps at all. i think this is due to some heritage from the times when a timestamp value also had a timezone value attached to it.
Examples of such bogus operations are timestamp+, timestamp-, all adjust-timestamp variants that operate on the components of a date value, etc.
It is mostly unrelated to timezones and different calendar systems (e.g. Julian, Gregorian), which are just ways to denote a timestamp in a way humans can easily deal with.
Some date-time fields may be left undefined.
A method defining how to denote a timestamp using a set of numbers (called year, month, day, etc). there are various such encodings like the Gregorian calendar, or the Julian calendar (which was in effect in Russia until 1922!). wikipedia has loads of info about these. We’ll default to a naive Gregorian calendar
essentially arithmetic on numbers denoting seconds. operations that would expose the epoch chosen by the implementation are not allowed (e.g. adding two timestamps), but things like adding/subbing literals and substracting two timestamps are valid.
(only in the mandatory context of a calendar system, which most of the time includes a timezone, too.)
, e.g. an rfc3339 string. note that such a date-time does not necessarily describe a timestamp completely. it only does so when it contains all the components needed by the calendar system to denote a sharp cut on the t axis.
although what those operations mean potentially depend on the calendar system and its parameters (e.g. the optional timezone value in it). also note that some operations are potentially undefined and signal an error with certain illegal values (e.g. instantiating a date using an illegal or contradictory combination of its parameters; setting a field to an illegal value like february 29 in leap years…)
(strictly in the context of a calendar system and a timezone)