[phobos] std.datetime and tick types

[SHOO]

(2010/09/27 20:22), Jonathan M Davis wrote:
> Well, it should be less then a week before I'm done (hopefully sooner rather
> than later), but I keep ending up having to refactor things, and I haven't
> always had as much free time as I expected, so it's been taking me longer than I
> expected. I'll post it here as soon as it's ready, and then everyone can review
> it.
>
> I don't know about your Duration, but normally a duration would be a value and
> units, while my ticks are just units. For instance, I declare this enum
>


Correct! You shouldn't see my 'std.time'. There is the doubt why poison 
is mixed with in the code.


> /++
>      Represents possible units of time.
>    +/
> enum TUnit { year, month, week, day, hour, minute, second, millisecond,
> microsecond, stdTick }
>
>
> to represent all the possible units of time (it was tick until I changed it to
> stdTick). Your Ticks, on the other hand, is a value with variable units, so it's
> kind of like a duration, except that it's specifically a duration since midnight
> January 1st, 1970. So, like time_t, it could be viewed as a duration (or as an
> interval for that matter since it has a fixed point for its start), but it's used
> more like a point in time. In fact, now that I think about it, in boost
> terminology, it really is a time point; it just lacks all of the trappings that
> let it work with durations, and intervals, and iterators/ranges, and the like.
> In any case, what my code means by tick (or stdTick) is totally different from
> what Ticks does.


Ticks is not a time point. It is rather near to a time span. It is a 
time span since indeterminate time point that may not be midnight
January 1st, 1970 and may be when you started a StopWatch.


> I'm tempted to rename Ticks to PrecisionTime or something similar, since that's
> more or less what it is. It's a time point with the maximum precision that the
> system clock has to offer. Unfortunately, even doing that doesn't quite fix the
> ticks problem, since it would still have ticksPerSecond. I'd be tempted to
> change it to the number of ticks in its precision (e.g. a clock with microsecond
> precision - 1 million ticks per second - would be 10 std ticks, whereas a clock
> with millisecond precision would be 1000 std ticks) - it would make it so that
> there was only one type of tick. Unfortunately, that falls apart once your
> precision goes beyond 10 million ticks per second (1 std tick), since then you'd
> get fractional std ticks, and any computer with nanosecond precision would
> obviously fall in that category. ticksPerSecond, at least, scales to no matter
> what resolution the system clock has.
>


Therefore I am against PrecisionTime.


> What I'd really like is to find a better name than tick or std tick for my ticks.
> What would that be anyway? A deci-microsecond? A centa-nanosecond? Either name
> would be horrible.
>
> As for merging your code, it's mostly been just copy and paste. The only things
> that I've changed thus far are adding the ability to get std ticks out of Ticks
> and fixing it so that Ticks works with precision less than a microsecond. For
> instance, toMicroseconds() is now
>
> const
> T toMicroseconds(T)() if (isIntegral!T&&  T.sizeof>= 4)
> {
>      if(ticksPerSec>= 1_000_000)
>          return value / (ticksPerSec / 1_000_000);
>      else
>          return value * (1_000_000 / ticksPerSec);
> }
>
> The problem was that dividing by 1_000_000 when the precision is less than that
> resulting in a floating point exception (I ran into it because I added std ticks
> and my system clock has microsecond precision). Other than that, your code is
> exactly as it is in std.datetime right now. Oh, and I had to add an alias for
> TemporaryValue, otherwise compilation failed when attempting to produce ddoc
> files.
>
> The one thing that I think that I'm going to change at this point is the name of
> the Ticks struct. The best that I can think of at the moment is PrecisionTime,
> but I'm open to suggestions (that is why I started this thread, after all).
>
> In any case, hopefully it won't be much longer before I'm able to post the
> finished result here for review.
>
> - Jonathan M Davis


Because your Ticks is completely different from mine, there must not be 
misunderstanding for each name.
SysSpan/SysDuration/SysPeriod/PerfSpan/PerfDuration/PerfPeriod/SysClockSpan/SysTicks/PerfTicks/PrecisionSpan/PrecisionDuration/PrecisionPeriod/...etc.
Please pick your favorite name.
I don't know English little nuances well... If the name does not provoke 
misunderstanding, I am not particular about the name.