[phobos] datetime review

[Jonathan M Davis]

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. Something as simple as having 12 months in a 
year is completely specific to a certain set of calendars. Sure, there's some 
leeway there since some calendars use very similar date types (like the Julian 
and Gregorian calendars), but once you deal with dates, you're pretty much 
committing yourself to a particular calendar. Code can obviously be written to 
convert between calendars, but I really don't think that it makes much sense to 
try and have a date type which is calendar agnostic. And since the vast majority 
of the planet uses the Gregorian Calendar, I really don't see much value in 
worrying about other calendars. I definitely think that trying to make a date 
type work with multiple calendars is going to needlessly complicate code for 
99.99% of programmers out there for the .01% who might maybe care. Date, 
DateTime, and SysTime all provide enough information to convert them to be able 
to convert them to another calendar type if someone wrote it.

I know that there are date/time/calendar libraries which try and be calendar 
agnostic, but I've never even heard of a program that used anything other than 
the Gregorian Calendar (though there are bound to be at least a few out there 
somewhere). Java's API, for instance, theoretically supports multiple calendars, 
but they've only ever implemented the Gregorian Calendar. Boost tried to make 
their code calendar agnostic,but I think that it's a lot harder to understand 
and far more fragmented becausje of it. And I don't think that they even have a 
non-Gregorian implementation either.

So, I can understand wanting to make a date/time library calendar agnostic, but 
I really don't think that it's worth the cost.

- Jonathan M Davis