Proposal for custom time string formatting in std.datetime

[Jonathan M Davis]

On Thursday, December 22, 2011 10:59:54 Andrei Alexandrescu wrote:
> This. YES. A liability of the current std.datetime is that it assumes
> that unittest code is exempt from the rules that apply to regular code.

I still don't agree with this at all, but there's no point in rehashing those 
arguments. I agreed to refactor the unit tests, and I've refactored some of 
them based on those complaints. I just haven't finished the job yet.

> I am increasingly worried about that module. It has been argued that its
> sheer size is not a problem, but somehow the task of accounting for that
> has taken a life of its own - e.g. we can't test std.datetime like
> everything else in Phobos, it needs its own version.

Any time that breaking it up has come up, it's been voted down. I don't 
personally find the size to be a maintainability issue at all, but it _is_ an 
issue as far as the documentation goes, since it makes the module harder to 
understand in spite of the fact that the basic design is fairly simple. Also, 
it's caused issues for Don when reducing compiler bugs, because he needs to 
strip out the unit tests, and there are a lot (and there still will be even if 
they're refactored, just because there's a lot to test). That's the main 
reason that the version identifier for the tests is still there.

I'm not against breaking up std.datetime as long as its broken into an actual 
package. Pieces of it can be broken out without that (e.g. the interval and 
range stuff), but I'm not sure that that would really reduce the size of the 
module enough to really fix the complaints on that front.

- Jonathan M Davis