From: Michal Suchanek <hramrach@...>
Date: 2008-08-25T20:49:54+09:00
Subject: Re: Chronos - A project needs your help

Discalimer: I am not seeing myself using the library anytime soon,
except perhaps for generating New Year cards about 10 times a year.

Still I am somewhat interested in the problems involved in counting
time by different calendar systems, and you requested your bikeshed
painted so here goes my colour suggestion.

First I would like to say that the math rules you describe in
NOTES.rdoc sound quite reasonable. There are only a few corner cases
where I do not see the behaviour specified or where there might be
alternate uses.

As a person living in a DST timezone I find DST confusing as it is and
I would prefer any date to be in the normalized format with correct
DST for the time of the year at all times, that is with auto
normalization. I realize this is not possible to do for all times but
an option to turn on normalization for times for which the DST status
is known might be helpful. Also it should be expected the DST won't
change in the future until it changes because otherwise it is not
possible to determine what time it will be tomorrow around this time
of the day.
Automatic normalization might add more imprecision to the already
imprecise calculation but there might be an option to turn it off, and
there is always the option to convert the time into GMT or seconds
since epoch or another format for precise calculations.

As I understand it there is Interval (which spans from one exact point
in time to another exact point in time), and Duration (which spans
some number of years, months, days,hours,etc).

It looks like adding a duration to a time gives the expected civil
semantics ( +1 year +month = at the same time of the day the same day
of the next month of the next year). For precise (ie astronomical)
calculations using durations in seconds would be probably more
appropriate.

And this leads to the question how to convert the Intervals do
Durations. Given both ends of the interval are in the same calendar it
makes sense to convert to a civil duration as years, months, etc.
However, business planning may favour durations in months or weeks
(and days, etc), precise calculations in seconds. Perhaps the
conversion could be parametrized by "acceptable units" - a parameter
which names units acceptable in the resulting duration.

Converting interval which has one end in Gregorian and the other end
in Julian or even stardate to anything but seconds does not seem very
meaningful. There is nothing stopping the user from converting all
dates to a single calendar before calculating the duration, though.

Thanks