[local-time-devel] non-intuitional behavior of adjust-timestamp and timezones

[Attila Lendvai]

ok, i think this is the result of a bit of confusion in the code which
i'll try to sum up now.

first of all many of the operations currently defined on timestamps by
the local-time lib should not really be defined on timestamps. 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.

let's define the nomenclature first:

 - timestamp: a value representing a sharp cut on the continuous t
axis (as in physics), and as that it is completely unrelated to
timezones and dates.

 - calendar: defines an encoding how to point to 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.

 - date: packages a mandatory calendar, an optional timezone and a
possibly partial set of the above mentioned numbers. (note that this
is a bit more flexible than what the everyday usage of the word 'date'
suggests, more like a partial-timestamp, but i'd like to keep
'timestamp' away from this to make clear the difference between them.
i'm open for alternative names.)

operations defined on timestamps:
 - set or offset the unit of the time axis, namely seconds.

 - convert to/from date (only in the context of a mandatory calendar
and a mandatory timezone)

operations defined on dates:
 - construct from string representation, e.g. an rfc3339 string. note
that such a timestring does not necessarily describe a timestamp, only
when it contains all the components down to seconds, and a timezone
offset and a calendar is also provided.

 - set/offset any component of it, although what those operations mean
potentially depend on the mandatory calendar and the optional timezone
 value in it. also note that some operations are potentially undefined
and signal an error with certain date values (e.g. illegal combination
of numbers describing a valid date)

 - convert to/from a timestamp (strictly in the context of a calendar
and a timezone)

does it make sense? anybody full of fresh creative force and free time
jumping up to implement it?

-- 
 attila

ps: it got on my TODO, but it's way too long...