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 _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
