[phobos] Status of std.gregorian

[Jonathan M Davis]

On Sunday 15 August 2010 05:36:08 Andrei Alexandrescu wrote:
> Thanks for your work, Jonathan. Our decision after the issue with
> Tango's date and time was to use Boost's. I'd started std.gregorian as a
> seed of a port of Boost's date and time, in the hope that someone will
> continue it. Jeff Garland (Boost's date/time author) has been very
> supportive in the matter.
> 
> I very strongly suggest to stick with copying Boost's or C++0x's date
> and time facilities, unless we find some clearly superior ways
> facilitated by D's features. Developing our own date/time library from
> scratch risks of being at best just as capable as Boost/C++0x but
> guaranteed unfamiliar to everyone.

Okay. I've started looking at boost's date/time stuff, and they do appear to 
maintain time internally in UTC rather than converting it to local time, which 
was my biggest fear, since I've run into a lot of problems with that sort of 
thing in the past. So, overall, I'd say that it looks quite good (this _is_ 
boost after all). I do have a few concerns, however.

1. I'd argue that the boost date/time libraries are way too complex for normal 
usage. If you want to do detailed date/time stuff, they look incredibly flexible, 
but I'd be very worried that for the average case they're seriously overkill. 
I'd be worried that programmers looking for basic date/time functionality will 
quickly get lost in dealing with the full boost implementation and that they 
would do better to have a seriously simplified date/time facility without all of 
the bells and whistles. That's not to say that we shouldn't implement the boost 
stuff in Phobos, but I'd be concerned if it were the only date/time facility 
available.

2. We're looking at least 3 modules for this - gregorian, local_time, and 
posix_time. Ideally, they'd be something like std.time.gregorian, 
std.time.local_time, and std.time.posix_time, but thus far we've avoided 
multiple levels of modules in the std hierarchy. Depending on the 
implementation, having package level access between them may be desirable (not 
having ported it all, I can't say for sure), and I think that it's fair to say 
that we wouldn't want to give all of std package-level access to the 3 of them 
(though hopefully package-level access wouldn't be required). So, it needs to be 
decided whether we want the three modules to be at a deeper level than std in 
the package hierarchy (and those modules are likely to be _big_ even _without_ 
solid unit tests - they're split up quite a bit among source files in C++).

3. Do you care whether the internals are the same or if the API is absolutely 
identical (or at least as identical as reasonably possible when going from C++ 
to D)? Already, looking at Date, I question the choice of maintaining its state 
as the number of days rather than a separate year, month, and day. I've 
implemented a good chunk of it with year, month, day, and I think that the code 
is much cleaner that way. I also have to wonder why on earth they picked 
1400-01-01 as the oldest date possible since that seems arbitrarily recent, and 
depending on why that is, it would seem desirable to me to make it more flexible 
than that. In any case, I would hope that as long as the API and functionality 
is correct that I wouldn't have to port over its internals exactly, and I would 
hope that there wouldn't be a problem in adding functionality if it seems 
obviously valuable. And of course, some of it may make sense if the were made 
closer to how idiomatic D does things (like possibly make time durations 
ranges).

So, looking over it, the Boost stuff does look quite good but also very complex. 
I'm perfectly willing to spend time porting it over, and I've already done a 
fair bit of work with it (though there's a _long_ way to go), but I do think 
that we need another, easy-to-use date/time facility for the average use case. A 
fixed up std.date might be good enough for that, but full-on boost is just too 
much for the average case and is going to scare off a lot of programmers who just 
want to be able to get the date and do minimal stuff with it.

- Jonathan M Davis