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 >> [email protected] >> 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. _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
