[phobos] datetime review

[Michel Fortin]

Le 2010-10-11 à 23:12, Jonathan M Davis a écrit :

> On Monday 11 October 2010 19:46:15 Michel Fortin wrote:
>> Le 2010-10-11 à 13:19, Jonathan M Davis a écrit :
>>> On Sunday, October 10, 2010 09:20:31 Michel Fortin wrote:
>>>> Another option I might propose is to get rid of MonthDuration by using
>>>> JointDuration instead and rename it to CalendarDuration.
>>>> 
>>>> But in my opinion, calendar things like this should simply belong to a
>>>> separate module. This would simplify the API for those who don't need to
>>>> deal with the complexities of the calendar.
>>> 
>>> That's not an entirely bad idea, but since any types which deal with
>>> durations would have to know about CalendarDuration, it wouldn't really
>>> help much. And while I completely agree that we want to make the more
>>> advanced features not get in the average users way, most of the calendar
>>> stuff is built into the types themselves, so you can't really create a
>>> calendar module to hold it.
>> 
>> I'm aware that my suggestion doesn't fit very well the structure of your
>> code. Personally, that the calendar stuff is built into the type
>> themselves is what makes me a little uneasy with the current design;
>> otherwise I like this API. But extracting calendar stuff would require
>> rethinking a couple of things, I'm not too sure if it's worth it.
>> 
>> For instance, you say "any types which deal with durations would have to
>> know about CalendarDuration", but you can generally fix that by making the
>> duration responsible for the appropriate convertions. For instance, adding
>> a duration to a timestamp could involve calling a function
>> "duration.hnsecDurationFrom(timestamp)" to convert the duration in
>> hnseconds. HNSecDuration would simply return itself while CalendarDuration
>> would do the conversion based on the given timestamp. And the day someone
>> wants to implement JapaneseCalendarDuration (or any other kind of
>> duration), he'll just have to implement this function on his duration
>> type.
>> 
>> I'm wondering if this can be implemented without too much code.
> 
> Once you deal with any kind of date, you have to deal with a calendar, since all 
> dates are specific to a calendar.

I disagree.

A date can be expressed using different calendars, but can also be stored as an interval since a reference date (like the UNIX epoch). With your main storage format calendar-agnostic you can easily convert back and forth to different calendars-specific formats.

Also, if you're dealing only with time -- like calculating the time elapsed between two time points -- then you don't need any calendar unless you plan to display that elapsed time in months or years.

And of course I never meant that Phobos should provide more calendars than gregorian. That said, it'd be good if it its gregorian implementation could be used as a base to implement other calendars.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/