std.gregorian

[Steven Schveighoffer]

On Mon, 03 May 2010 13:46:12 -0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> FWIW, I have used boost date_time in the past, but I didn't really like  
>> it.  Particularly the part where every unit is its own type (dunno,  
>> that may have changed, it was several years ago that I used it).  If we  
>> could try to combine these types together, I think it would be  
>> beneficial.
>
>
> I haven't looked at that Boost package, but the idea behind that is if  
> month and year have different types, bugs where a year value is mistaken  
> for a month can be headed off at compile time. There's some modern  
> thought that this is a good style for programming. We'll see how it pans  
> out.

I was thinking more about how hours, minutes, seconds, etc. each have  
their own type.

I think they do this so declaring literals is somewhat natural:

// borrowing D's auto
auto ts = hours(1) + minutes(20) + seconds(5);

But I think these can all be global functions which return the same type,  
rather than returning individual types.

Actually, looking at the docs again, it appears that hours, minutes,  
seconds, etc. are classes, but just basic classes derived from  
time_duration, and sole purpose of them is to construct time_duration, but  
it's very odd they didn't just use a function.  Can anyone think of why  
they would have done it this way?

Months and years, actually, I could understand having their own (common)  
type, since adding x months in terms of some standard time unit such as  
seconds is not trivial.  This non-trivial calculation would only need to  
take place when adding months to a ptime.  Adding months to months would  
be straightforward, and adding time_duration/ptime/time_period together  
would be straightforward.  That would be a cool feature, the way we solved  
it in Tango is to have a function in the calendar called addMonths, but  
having a general "this represents a number of months" entity could be nice  
for things like iterating over a time period x months at a time...

Actually, more bikeshedding, can we make the type names better?   
time_duration, time_period, ptime, ugh....

I like TimeSpan (or Span), TimePeriod, Time.

-Steve