"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a829dg$qva$1@digitaldaemon.com...
> OK, You've all convinced me, and I am outnumbered anyhow :)
> Can anyone point me to a location where I can get some specs
> on datetime formats, because I would like to try writing
> a datetime module...

I posted the OLE format in another post in this thread. Found it on google <g>.

"Walter" <walter@digitalmars.com> wrote in message news:a826te$69l$1@digitaldaemon.com...

> I think by using careful typedef's for the time, whether it is a 64 bit
int
> or a 128 bit int or milliseconds or microseconds, etc., will be an implementation issue. The programmer will just use the typedef's and the api's for it, and it should not be relevant to him what the underlying representation is.

Is it a good idea? I mean, when you do (a - b), you don't know whether the result is in milli-, micro-, or nanoseconds... probably it is better to fix measuring units, but vary size - int64, int128 etc.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a82foe$2ked$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a826te$69l$1@digitaldaemon.com...
> > I think by using careful typedef's for the time, whether it is a 64 bit
> int
> > or a 128 bit int or milliseconds or microseconds, etc., will be an implementation issue. The programmer will just use the typedef's and the api's for it, and it should not be relevant to him what the underlying representation is.
> Is it a good idea? I mean, when you do (a - b), you don't know whether the result is in milli-, micro-, or nanoseconds... probably it is better to fix measuring units, but vary size - int64, int128 etc.

You have a constant like CLOCKS_PER_SECOND.

"Walter" <walter@digitalmars.com> wrote in message news:a82km3$2m2l$1@digitaldaemon.com...

> > Is it a good idea? I mean, when you do (a - b), you don't know whether the result is in milli-, micro-, or nanoseconds... probably it is better to fix measuring units, but vary size - int64, int128 etc.
>
> You have a constant like CLOCKS_PER_SECOND.

So, (a - b) / CLOCKS_PER_SECOND? But this means additional division,
which is not that good in time-critical situations (where timers
are used frequently).

Hm, and what's the problem with fixed units? Microseconds seem
to be enough for most purposes, WHY would somebody decide
to use something else in his implementation? Isn't it just better
to standartize it?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a82n5c$nqn$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a82km3$2m2l$1@digitaldaemon.com...
> > > Is it a good idea? I mean, when you do (a - b), you don't know whether the result is in milli-, micro-, or nanoseconds... probably it is better to fix measuring units, but vary size - int64, int128 etc.
> > You have a constant like CLOCKS_PER_SECOND.
> So, (a - b) / CLOCKS_PER_SECOND? But this means additional division,
> which is not that good in time-critical situations (where timers
> are used frequently).

The divide is only necessary when doing the report, which is not performance critical. (I've written profilers using the cycle timer instruction on the Pentium.)

> Hm, and what's the problem with fixed units? Microseconds seem
> to be enough for most purposes, WHY would somebody decide
> to use something else in his implementation? Isn't it just better
> to standartize it?

That's what people did years ago when unix time was in seconds. It worked for a couple decades, then there was all the falderol because it needed to change <g>.

"Walter" <walter@digitalmars.com> wrote in message news:a82rr9$2e3f$1@digitaldaemon.com...

> The divide is only necessary when doing the report, which is not
performance
> critical. (I've written profilers using the cycle timer instruction on the
> Pentium.)

Not really. Suppose I want something to happen in one mcs after:

    time t = clock();
    ...
    if ((clock() - t) / CLOCKS_PER_SEC / 1000000 >= 1)
        // do it

> That's what people did years ago when unix time was in seconds. It worked for a couple decades, then there was all the falderol because it needed to change <g>.

Then, use two longs, and nanosecond precision. THIS is going to be enough just for everybody.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a83g0b$1slr$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a82rr9$2e3f$1@digitaldaemon.com...
> > The divide is only necessary when doing the report, which is not
> performance
> > critical. (I've written profilers using the cycle timer instruction on
the
> > Pentium.)
> Not really. Suppose I want something to happen in one mcs after:
>
>     time t = clock();
>     ...
>     if ((clock() - t) / CLOCKS_PER_SEC / 1000000 >= 1)
>         // do it

Try this for, say, a delay of 1 hundreth of a second:
    if ((clock() - t) >= CLOCKS_PER_SEC / 100)

The division is done at compile time.

"Walter" <walter@digitalmars.com> wrote in message news:a83kjb$1vtr$2@digitaldaemon.com...

> Try this for, say, a delay of 1 hundreth of a second:
>     if ((clock() - t) >= CLOCKS_PER_SEC / 100)
>
> The division is done at compile time.

Okay, you've catched me =)

But... not so fast! I don't like the name of the constant! =) Probably something like TicksPerSecond would be better?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a849mg$2kim$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a83kjb$1vtr$2@digitaldaemon.com...
> > Try this for, say, a delay of 1 hundreth of a second:
> >     if ((clock() - t) >= CLOCKS_PER_SEC / 100)
> > The division is done at compile time.
> Okay, you've catched me =)

It's an old trick <g>.

> But... not so fast! I don't like the name of the constant! =)

Nobody's ever happy!

> Probably something like TicksPerSecond would be better?

Probably. I just threw out the former because that's what C uses.