[phobos] next release

[Jonathan M Davis]

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.

- Jonathan M Davis