datetime review part 2 [Update 4]

[Tomek Sowiński]

Jonathan M Davis napisał:

> On Thursday, November 11, 2010 16:31:56 Tomek Sowiński wrote:
> That would require you to be able to have unary +. I didn't think that
> that was legal. Upon checking it out though, it looks like it is. I don't
> really have any problem with the way that I did it, but I can see where
> you're coming from. I'll look at reducing some of those functions in a
> manner similar to that.

Thanks.

>> BTW, I still think units of time should be an enum, not a string.
> 
> No, strings are definitely better. I had an enum originally, and it was
> unusable in comparison. The main problem is that you have to always
> preface enum values with the enum name - either that you create an
> anonymous enum, but then you've got the problem that incredibly common
> terms such as years and seconds are now useless as variable names. The
> strings were Andrei's suggestion, and I think that they're a definite
> improvement. It's a bit harder to work with them internally in some places
> (such as when dealing with one unit being greater than another), but it's
> definitely a net gain.

Interesting. I've always preferred enums but what you're saying does make sense. I'm curious how it 
pans out.

> Well, I can't really include both long and short names very cleanly in a
> named enum (especially when there's code that relies on the order and
> value of the values). It really should be one or the other, though I'm
> open to using the short names rather than the long names for the days of
> the week.

If I had to choose one convention, it'd be it. Literals rarely come up in production code, more likely in 
unittests where clipping them short makes sense.

>> Designing the interface and, more importantly, solving how to store the
>> holiday information to allow fast interval querying is not
>> locale-specific. Plus, it is in common need for business, and it is not
>> trivial -- ideal candidate for the standard library. Then everyone can
>> write an implementation for their favorite country or stock exchange on
>> their own.
> 
> I'm certainly not against adding such functionality to std.datetime, but I
> hadn't considered it, and I think that what I have needs to be
> appropriately refined and then included into Phobos before looking at
> adding major new functionality. I would like to add stuff like date
> recurrence patterns in the future, and if there is any commonly useful
> date/time stuff which isn't too localized, adding it to std.datetime could
> make a lot of sense, but I'd like the base done first.

Amen. Dates are priority. Then we'll think of higher-level structures/operations. Besides, I haven't 
heard of a framework which has business day/holiday calculation really figured out, so the design will 
probably have to be done from scratch.

-- 
Tomek