On Mon, 03 May 2010 13:46:12 -0400, Walter Bright
<[email protected]> 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
