[phobos] std.datetime and tick types

[Jonathan M Davis]

On Monday 27 September 2010 02:25:55 SHOO wrote:
> I recognize that there is some confusion for a name of Ticks.
> I have been troubled about it once before, the time when my 'std.time'
> was discussed. I adopted Ticks because there was not name confused at
> that time. There were only types that named Ticks, Duration, Time and
> Date. Perhaps I suppose that your Ticks of this time is equivalent to my
> Duration.
> This time, I agree about changing name to merge your code.
> I want to see your merged code once. And then I want to evaluate it.
> 
> I'm looking forward to seeing your code.

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

/++
    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.

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.

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