Chronos - A project needs your help

Ruby
1

Summarized for those who don’t like long texts first :slight_smile:

What is Chronos?
A high level library to deal with date, time, duration and intervals.
Providing an interface for multiple calendary systems.

Where do I find Chronos?
On rubyforge: http://rubyforge.org/projects/chronos
On github: GitHub - apeiros/chronos: A high level time library, dealing with date, time, durations, intervals and more
Beware: I released it by deadline. This means it is a prerelease and
several things are still non-functional. I only released it now already
to gather input and rally help.

What help do you need?

  • I need to know what behaviour you expect in certain ambiguous
    situations, see NOTES.rdoc for some of those cases.
  • Translations to other languages, I can do en_U, de_DE, de_CH and
    de_AT. But for pretty much all others I need contributions
  • Calendary systems: I did Gregorian and probably will also do Julian
    (as it’s just a simpler version of Gregorian), but for all other
    calendary systems, I will need contributions (e.g. chinese, hebrew and
    discordian calendary systems - there are most certainly more)
  • Documentation: please read the docs and tell me where they are unclear
    and how one could improve them. Even more appreciated: write
    doc-patches.
  • Specs: add specs, the more the better.

Under what condition do you accept contributions?
They all have to be made available under the ruby license. If you
contribute, you do agree to this condition. I can’t have chronos be
fractured into multiple licenses depending on which author wrote a
piece. I hope you can understand that.
Also chronos is not design by committee. While I’m open for suggestions
and arguments (preferably via #ruby-lang on IRC, or if necessary in a
separate channel) I will have the last word on design questions.

Anything else I should know?
Yes. Please read the files in dev/, also README.rdoc and NOTES.rdoc. Be
aware that the library is currently under active refactoring and some of
the notes and actual implementation might not match up.
Also please use rubyforge’s bugtracker and feature-request tracker to
submit bugs and feature requests. This makes it easier for me to track
them.

And now the long text:
For a long time I struggled with Time, Date and DateTime. All of them
fall short in several regards. For that reason I started the chronos
project. Its aim was to provide a comprehensive solution for
Date/Time/Duration/Interval related problems with a better interface and
more flexibility.
Unfortunately the nature of Date and Time (at least in the gregorian
calendary system) is rather irregular and no matter how you solve a
problem, you will always break some peoples expectations.
This is one reason I need help. I need to know what people other than
myself expect in ambiguous situations. Also my approach with chronos is
to have some calendary system agnostic classes. Those can be subclassed
by calendary system aware classes to provide support for those
calendars. I can’t (knowledge- and timewise) implement any other
calendary system than Gregorian and Julian. So I need help to add other
calendary systems.
Also since I’m doing this project in my spare time (of which I no longer
have too much unfortunately) I need help with other aspects of the
project. Documentation, spec-writing, debugging, adding features.

I hope there are more people who are dissatisfied by what Time, Date and
DateTime provide and help to bring this project to fruition.

Regards
Stefan (apeiros)

2

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

3

Seems I did a bad job in advertising Chronos :slight_smile:
Unfortunately I’m quite a bit tired, but I’ll post tomorrow why a good
datetime/duration etc. library is important.
Thank you very much for your reply. I will answer your questions as good
as I can.

Michal S. wrote:

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.

Counting the time is trivial. It’s a distance in number of days +
picoseconds from an origin (backdated gregorian 0000-01-01 in case of
chronos). Each calendary system then converts that to the entities it
possesses. E.g. year, month, day, weeknumber, weekday etc. for the
gregorian and julian calendar.

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.

Thanks. I see that I omitted to mention the rationale behind this
decision. I too live in a country that has DST, so I know some of the
issues with it. Since not everybody might, here some issues DST brings:
DST is non-algorithmical. DST is only known for the past, for the
future, it isn’t certain. This is more true for some countries than for
others. This can also mean that if you autonormalize, that a time
displayed for a stored event changes from one run to the other if you
update the lookup-tables inbetween. This non-algorithmicality is IMO the
main issue we’re dealing with here.
Another issue is perception. If I add 24h to a datetime, I expect the
result to display the same clock. If math with dates & durations
respects DST, this is not guaranteed. So e.g. things that are scheduled
weekly couldn’t be calculated and displayed by iterating and adding 1
week per iteration as it’d suddenly shift ±1h.
The last issue involved with this is consistency.
So the rationale for my solution of requiring explicit DST normalization
was, that if you do want DST normalization, then you’re aware of the
implications (1h representation shift). If you’re aware, you can
conciously choose and accept those implications by explicitly stating
that you want your result normalized. If you’re unaware (for whatever
reason), then DST will stay completly out of your way. By keeping the
DST setting, the result is also correct, as that the time between the
two datetimes is indeed what you added/subtracted.

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).

That is correct.

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.

There are calendary specific Durations and Intervals. Durations and
Intervals store all atomic units. For gregorian this is months and
picoseconds (for technical reasons also days).
A gregorian interval stores the generic duration and the gregorian
duration.

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.

The above should give the answer to that question. You can convert a
gregorian interval to a gregorian duration (what you call civil
duration) or to a duration (calendary agnostic, just days and
picoseconds).

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.

Agreed. I have not yet made up my mind how to deal with Intervals with
different calendary system endpoints. I see two options:

  • Raise an ArgumentError (my current preference)
  • Make the Interval a Chronos::Interval (which would mean it’s calendary
    system agnostic)
    I prefer the argument error one as I’d assume it likely to be a mistake.
    The latter behaviour could still be achieved by converting both end
    points to Chronos::Datetime’s (which is calendary agnostic).

Thanks
Thank you :slight_smile:

Regards
Stefan (apeiros)

4

On Monday 25 August 2008 05:08 pm, Stefan R. wrote:

Seems I did a bad job in advertising Chronos :slight_smile:

Sorry, I haven’t read all the details here, but I wanted to mention that
when
I worked on business / process control applications, I found that the
best
way to deal with DST (and time zones) and so forth, was to always do
everything (within the computer) based on GMT (well, except when we
based it
on a monotonically increasing counter/timer).

Then, for display and/or reporting purposes, we converted to local time
(including adjusting for DST, if appropriate).

Randy K.

5

On Sun, 24 Aug 2008 17:11:26 -0500, Stefan R. wrote:

Summarized for those who don’t like long texts first :slight_smile:

What is Chronos?
A high level library to deal with date, time, duration and intervals.
Providing an interface for multiple calendary systems.

appreciated: write doc-patches.

  • Specs: add specs, the more the better.

Could you or some other contributor port the tzfile library to Chronos,
so that Chronos::Zone can use the system’s timezone existing library on
Linux?

6

On 25/08/2008, Stefan R. [email protected] wrote:

Seems I did a bad job in advertising Chronos :slight_smile:
Unfortunately I’m quite a bit tired, but I’ll post tomorrow why a good
datetime/duration etc. library is important.

I can see the utility of such library but I am currently not involved
in any project that would make use of it.

Counting the time is trivial. It’s a distance in number of days +
picoseconds from an origin (backdated gregorian 0000-01-01 in case of
chronos). Each calendary system then converts that to the entities it
possesses. E.g. year, month, day, weeknumber, weekday etc. for the
gregorian and julian calendar.

I would go as far as using only seconds/picoseconds because days might
vary in length between different calendars. However, using some
“standard days” to get a fixed point in time is time unit as good as
any other.

DST for the time of the year at all times, that is with auto

Thanks. I see that I omitted to mention the rationale behind this
decision. I too live in a country that has DST, so I know some of the
issues with it. Since not everybody might, here some issues DST brings:
DST is non-algorithmical. DST is only known for the past, for the
future, it isn’t certain. This is more true for some countries than for
others. This can also mean that if you autonormalize, that a time
displayed for a stored event changes from one run to the other if you
update the lookup-tables inbetween. This non-algorithmicality is IMO the
main issue we’re dealing with here.

It depends on the format in which you store the event. If you store it
in local time you are probably interested in the local time of the
day, and if the lookup tables change in between only the DST changes,
not the apparent time. If you store the time as GMT or something like
that the time would indeed change but you were interested in the
global time of the event then so it should be expected. If not then it
is likely a mistake.

Another issue is perception. If I add 24h to a datetime, I expect the
result to display the same clock. If math with dates & durations
respects DST, this is not guaranteed. So e.g. things that are scheduled
weekly couldn’t be calculated and displayed by iterating and adding 1
week per iteration as it’d suddenly shift ±1h.

This is not unlike adding and substracting months. Either you add
certain number of smaller units (24h for day, 30days for month) and
expect more precise duration or you add the larger unit and expect the
same time except for the one part you have changed. I would find
adding a day and getting a different time of the day quite confusing.

The last issue involved with this is consistency.
So the rationale for my solution of requiring explicit DST normalization
was, that if you do want DST normalization, then you’re aware of the
implications (1h representation shift). If you’re aware, you can
conciously choose and accept those implications by explicitly stating
that you want your result normalized. If you’re unaware (for whatever
reason), then DST will stay completly out of your way. By keeping the
DST setting, the result is also correct, as that the time between the
two datetimes is indeed what you added/subtracted.

However. adding a day results in a different time of the day which is
unlike most of the other rules.

It looks like adding a duration to a time gives the expected civil
duration.
This gives only two options that might be suboptimal for some uses. I
was trying to point out that more flexibility in this area might
improve the general usefulness of this library.

Thanks

Michal