From: Stefan Rusterholz Date: 2008-08-26T06:08:56+09:00 Subject: Re: Chronos - A project needs your help 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 Suchanek 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) -- Posted via http://www.ruby-forum.com/.