[phobos] next release

[Sean Kelly]

On Sep 16, 2010, at 4:27 PM, Jonathan M Davis wrote:

> On Thursday, September 16, 2010 15:39:19 Sean Kelly wrote:
>> On Sep 9, 2010, at 5:25 PM, Jonathan M Davis wrote:
>>> Just so you know, I fully expect that the datetime code that I've been
>>> working on will be done in less than a month. It'll be at least a week
>>> (probably closer to two), but it certainly won't be in the range of a
>>> month. Now, how many changes will be required after it's reviewed, or
>>> whether it will be accepted at all, is another matter. But it shouldn't
>>> be all that much longer before I'm done.
>> 
>> There are a bunch of routines in druntime that could really use a
>> structured timespan representation (Boost actually even uses a full
>> SystemTime class for most of these) and I'm trying to work out the best
>> way to do this.  In Tango, the decision was to have the routines all
>> accept a long value that is the same resolution as the tick count from
>> TimeSpan, which is why everything currently works as it does.  I've always
>> hated this and would love to do something more structured, but
>> complications arise from possible redundancy or incompatibility with
>> std.time.  What I've done for now is duplicate Boost's time_duration
>> struct (as TimeDuration) into core.time, and I'm looking at using this for
>> Thread.sleep(), etc.  Thoughts?
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> For what I've done, I have an enum of possible time units : year, month, week, 
> day, hour, second, minute, second, millisecond, microsecond,  and tick (where a 
> tick is 100 nanoseconds). I then have a Duration struct which is templatized on 
> the time unit enum and takes a value. So, you end up with a Duration which which 
> has a value (which is a long) and a type of time unit (e.g. 10 seconds or 1000 
> days). All of the functions that take a Duration are templatized so they will 
> take any Duration with units that they're compatible with (the main problem with 
> making them compatible with _all_ time units being that you cannot convert 
> between years or months and any other units without a specific date because the 
> number of days in a month is not consistent).
> 
> How all that would be applied to core.time, I don't know. I'd have to look at 
> what it's doing.

It's pretty much a straight port of time_duration, described here:

http://www.boost.org/doc/libs/1_44_0/doc/html/date_time/posix_time.html#date_time.posix_time.time_duration

I haven't bothered with the operator overloading yet though.