# Chronos - A project needs your help **URL:** \ **Category:** Ruby\ **Created:** [August 25, 2008, 12:15am UTC](https://www.ruby-forum.com/t/chronos-a-project-needs-your-help/146747 "2008-08-25T00:15:37Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\ **Post date:** [August 25, 2008, 12:15am UTC](https://www.ruby-forum.com/t/chronos-a-project-needs-your-help/146747/1 "2008-08-25T00:15:37Z")
Summarized for those who don’t like long texts first 🙂 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](http://rubyforge.org/projects/chronos) On github: [GitHub - apeiros/chronos: A high level time library, dealing with date, time, durations, intervals and more](http://github.com/apeiros/chronos) 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) ---
**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\ **Post date:** [August 25, 2008, 1:54pm UTC](https://www.ruby-forum.com/t/chronos-a-project-needs-your-help/146747/2 "2008-08-25T13:54:34Z")
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 ---
**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\ **Post date:** [August 25, 2008, 11:13pm UTC](https://www.ruby-forum.com/t/chronos-a-project-needs-your-help/146747/3 "2008-08-25T23:13:16Z")
Seems I did a bad job in advertising Chronos 🙂 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 🙂 Regards Stefan (apeiros) ---
**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\ **Post date:** [August 26, 2008, 4:53pm UTC](https://www.ruby-forum.com/t/chronos-a-project-needs-your-help/146747/4 "2008-08-26T16:53:40Z")
On Monday 25 August 2008 05:08 pm, Stefan R. wrote: > Seems I did a bad job in advertising Chronos 🙂 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. ---
**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\ **Post date:** [August 28, 2008, 12:10pm UTC](https://www.ruby-forum.com/t/chronos-a-project-needs-your-help/146747/5 "2008-08-28T12:10:27Z")
On Sun, 24 Aug 2008 17:11:26 -0500, Stefan R. wrote: > Summarized for those who don’t like long texts first 🙂 > > 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? ---
**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\ **Post date:** [August 26, 2008, 9:52am UTC](https://www.ruby-forum.com/t/chronos-a-project-needs-your-help/146747/6 "2008-08-26T09:52:27Z")
On 25/08/2008, Stefan R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Seems I did a bad job in advertising Chronos 🙂 > 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