"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7t4d2$2jfd$5@digitaldaemon.com...

> Well, pretty large.  If you keep the crecision of microseconds, you are limited to something like 584,000 years.  I think that is enough.  If you want to go to nanosecond precision, then you are limited to 584 years,
which
> is probably enough in practice (with a base of say 1800 it will last till nearly 2400), but surely someone will object that it isn't sufficient.
>
> To avoid that argument, I would be quite willing to accept a precision of microseconds.

Agreed. I don't know why somebody would want to measure dates with
nanosecond
precision. Nanoseconds are used in timers, but you most likely aren't going
to have your program run for more than 500 years =)

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7t4db$2jfd$6@digitaldaemon.com...

> Note that the original poster suggested two 64 bit values, one for days
and
> one for time of day .  Using this idea, we have plenty of bits for time accurate to nanoseconds, (or even less) and dates even if you set the
start
> date to something like the big bang.  :-)

However, this requires twice more memory, and you can't just subtract one value from another, or compare dates, etc.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a7tdid$2o6t$1@digitaldaemon.com...
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7t4d2$2jfd$5@digitaldaemon.com...
>
> > Well, pretty large.  If you keep the crecision of microseconds, you are limited to something like 584,000 years.  I think that is enough.  If
you
> > want to go to nanosecond precision, then you are limited to 584 years,
> which
> > is probably enough in practice (with a base of say 1800 it will last
till
> > nearly 2400), but surely someone will object that it isn't sufficient.
> >
> > To avoid that argument, I would be quite willing to accept a precision
of
> > microseconds.
>
> Agreed. I don't know why somebody would want to measure dates with
> nanosecond
> precision. Nanoseconds are used in timers, but you most likely aren't
going
> to have your program run for more than 500 years =)

True, of course, but people might want to measure elapsed time in nanoseconds or time some precision event in nanoseconds (remember in a few years, 1 nanosecond will be something like 10 instructions on a then current CPU) and, in your other post, you objected to having date and time be separate variables because you couldn't handle time differences across midnight by a simple subtraction, etc.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7tm70$2sjd$1@digitaldaemon.com...

> True, of course, but people might want to measure elapsed time in nanoseconds or time some precision event in nanoseconds (remember in a few years, 1 nanosecond will be something like 10 instructions on a then
current
> CPU) and, in your other post, you objected to having date and time be separate variables because you couldn't handle time differences across midnight by a simple subtraction, etc.

You don't need a date variable to measure elapsed time - a simple ulong counter will do, and you can use arbitrary precision there, nanoseconds or whatever else... dates and timers are two different things, why mix them?

> 
> So, how about it? An extended for a datetime?
> 
Two problems which I see,
        1       converting time -> seconds is none trivial
        2       not all computers have extended precision floats
                (some do not even have double precision)

(Though the dates and up looking like Treky stardates - which should appeal to geeks :-)

Pavel Minayev wrote:

> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7t4db$2jfd$6@digitaldaemon.com...
> 
>> Note that the original poster suggested two 64 bit values, one for days
> and
>> one for time of day .  Using this idea, we have plenty of bits for time accurate to nanoseconds, (or even less) and dates even if you set the
> start
>> date to something like the big bang.  :-)
> 
> However, this requires twice more memory, and you can't just subtract one value from another, or compare dates, etc.
> 
Yes, that is a problem - and it a later post I suggested two 32 bit values would be be more efficient and nearly as effective.  I expect the date and time values to be used for time stamps on file systems etc,  not for nano second precision - that is the job of specialist timers (and besides the overhead of a call to the date/time routines could easily mess up a nano second count,  rendering its output effectively worthless).

The problem with storing date and time in a single 64 bit value is that leap _seconds_ are added (and subtracted) in an arbitrary way to compensate for planetary deceleration (ok,  it is not truly arbitrary but for our results it may as well be).  Do you really want programmes written in D to be a few minutes out compared to real time?  After all the purpose of a standard date/time library is to prevent such problems (even with people using different date and time representations) by using a standard format which is easily convertable.

Finally the date and time, if stored in separate 32 bit uints, could be
split up - if you want to know, for example, the date of a birthday the
time is commonly unimportant.  And if creating an alarm clock the date is
similarly unwanted.  Although addition and subtraction of dates in this
format is not as trivial,  comparasons are just as simple.
(add/sub -> time+=newTime; date+=newDate+time/secondsInDay;
time%=secondsInDay;  is that really that much more difficult - these
operations could easily be added to the time/date library)

        `       newTime <- eax          ` 586 timings (Intel)
        `       newDate <- ebx
        add     eax, time               ` 1     U
        xor     edx, edx                `       V
        `cwde   ` could be used - but c = 3 NP
        div     secondsInDay            ` 41    NP      (ouch)
        add     ebx, eax                ` 1     U
        mov     time, edx               `       V
        add     date, ebx               ` 1     U
                                        `== 44 total (&free slot [pop ebp?])
        ` ( time for 64 bit add is 4 cycles )
        ` ( nb: I think divides are faster on newer processors,  and they take
        `   less cycles on older processors (38-386,40-486) )

C       2002/3/28

"DrWhat?" <blackmarlin@nospam.asean-mail.com> wrote in message news:a7uu46$epg$1@digitaldaemon.com...
> >
> > So, how about it? An extended for a datetime?
> >
> Two problems which I see,
>         1       converting time -> seconds is none trivial


alias DateTime extended;

DateTime dt = 3.25;
DateTime date = (long) dt;
DateTime time = dt - date;

// time is a fraction of a day.
// 1 Day == 24 hours, so mul. time by 24 to get hours...
DateTime hours = time * 24;

// 1 Day == 1440 minutes, so mul. time by 1440 to get min... DateTime min = time * 1440;

// 1 Day == 86400 seconds, so mul. time by 86400 to get sec... DateTime sec = time * 86400;

Ofcourse you could go on for milliseconds, microseconde,
nanoseconds etc... To me it seems quitte trivial, or am
I missing something important?

Also, this format is used by Ole DATE and the MFC
COleDateTime and Delphi TDateTime classes, both of
which come with source, so getting all the other
algorithms should be easy.

>         2       not all computers have extended precision floats
>                 (some do not even have double precision)
>

OK, Fair enough...
So, buy a new computer! Sounds very bulish, I admit,
but some processors don't have 32-bit addressing either,
but it didn't stop Walter from making that the lowest
supported format for D. And fully justified too I think.
We have to look for the future, not always back at the
past...
How about this: If there are common 32-bit processors
that do not support 80-bit extended, go for 64 bit
double instead. If they all support it, use 80 bit, we
want precision, not speed, because most 3D graphics
do not need dates! :)

Conversion to and from double to extended is easy
anyway as long as you stay within the safe range.
When you go out of range you have just proven that
we actually *need* 80 bits!


> (Though the dates and up looking like Treky stardates - which should
appeal
> to geeks :-)

LOL! You got me, that's why I like it!  :)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"DrWhat?" <blackmarlin@nospam.asean-mail.com> wrote in message news:a7v0f9$ger$1@digitaldaemon.com...
> Pavel Minayev wrote:
>
> > "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7t4db$2jfd$6@digitaldaemon.com...
> >
> >> Note that the original poster suggested two 64 bit values, one for days
> > and
> >> one for time of day .  Using this idea, we have plenty of bits for time accurate to nanoseconds, (or even less) and dates even if you set the
> > start
> >> date to something like the big bang.  :-)
> >
> > However, this requires twice more memory, and you can't just subtract
one
> > value from another, or compare dates, etc.
> >
> Yes, that is a problem - and it a later post I suggested two 32 bit values would be be more efficient and nearly as effective.  I expect the date and time values to be used for time stamps on file systems etc,  not for nano second precision - that is the job of specialist timers (and besides the overhead of a call to the date/time routines could easily mess up a nano second count,  rendering its output effectively worthless).
>
> The problem with storing date and time in a single 64 bit value is that leap _seconds_ are added (and subtracted) in an arbitrary way to
compensate
> for planetary deceleration (ok,  it is not truly arbitrary but for our results it may as well be).  Do you really want programmes written in D to be a few minutes out compared to real time?  After all the purpose of a standard date/time library is to prevent such problems (even with people using different date and time representations) by using a standard format which is easily convertable.
>
> Finally the date and time, if stored in separate 32 bit uints, could be
> split up - if you want to know, for example, the date of a birthday the
> time is commonly unimportant.  And if creating an alarm clock the date is
> similarly unwanted.  Although addition and subtraction of dates in this
> format is not as trivial,  comparasons are just as simple.
> (add/sub -> time+=newTime; date+=newDate+time/secondsInDay;
> time%=secondsInDay;  is that really that much more difficult - these
> operations could easily be added to the time/date library)
>
>         `       newTime <- eax          ` 586 timings (Intel)
>         `       newDate <- ebx
>         add     eax, time               ` 1     U
>         xor     edx, edx                `       V
>         `cwde   ` could be used - but c = 3 NP
>         div     secondsInDay            ` 41    NP      (ouch)
>         add     ebx, eax                ` 1     U
>         mov     time, edx               `       V
>         add     date, ebx               ` 1     U
>                                         `== 44 total (&free slot [pop
ebp?])
>         ` ( time for 64 bit add is 4 cycles )
>         ` ( nb: I think divides are faster on newer processors,  and they
take
>         `   less cycles on older processors (38-386,40-486) )
>
> C       2002/3/28

So use an OLE DATE compatible format, 64 bits float.
This way splitting date and time is very easy, you
don't need to invent difficult routines (MFC
COleDateTime and Delphi TDateTime routines are open-
source and all the problems you mention have been
solved by other people before. Also, you get instantly
free compatibility with OLE.

See my other post...


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

OddesE wrote:

> "DrWhat?" <blackmarlin@nospam.asean-mail.com> wrote in message news:a7uu46$epg$1@digitaldaemon.com...
>> >
>> > So, how about it? An extended for a datetime?
>> >
>> Two problems which I see,
>>         1       converting time -> seconds is none trivial
> 
> 
> alias DateTime extended;
> 
> DateTime dt = 3.25;
> DateTime date = (long) dt;
> DateTime time = dt - date;

(need a multiply here,  then another conversion to convert to seconds
before we can even think of converting it into a national standard).
total - 3 conversions, 1 subtract, 1 multiply.
That is going to take even more processor cycles that my solution,  and may
have some problems in terms of precision.  Also why use the FPU when there
is no need,  especially when it is less efficient.  But that is not the
real problem.

> // time is a fraction of a day.
> // 1 Day == 24 hours, so mul. time by 24 to get hours...
> DateTime hours = time * 24;
> 
> // 1 Day == 1440 minutes, so mul. time by 1440 to get min... DateTime min = time * 1440;
> 
> // 1 Day == 86400 seconds, so mul. time by 86400 to get sec... DateTime sec = time * 86400;

Wrong - 1 Day may equal 86399 or 86401 seconds - remember leap seconds, they are a problem when converting dates into seconds,  and that is the problem I am trying to avoid.

> Ofcourse you could go on for milliseconds, microseconde,
> nanoseconds etc... To me it seems quitte trivial, or am
> I missing something important?
> 
> Also, this format is used by Ole DATE and the MFC
> COleDateTime and Delphi TDateTime classes, both of
> which come with source, so getting all the other
> algorithms should be easy.

I do not programme or even use Windows,  I could not comment on this.

>>         2       not all computers have extended precision floats
>>                 (some do not even have double precision)
>>
> 
> OK, Fair enough...
> So, buy a new computer! Sounds very bulish, I admit,
> but some processors don't have 32-bit addressing either,
> but it didn't stop Walter from making that the lowest
> supported format for D. And fully justified too I think.
> We have to look for the future, not always back at the
> past...

I think a flat memory model is necessary for D not necessarily 32 bit addressing - this would rule out the 8086 but still allow porting to ie. the Z80 or similar embedded system CPUs with a 16 bit flat memory model.

> How about this: If there are common 32-bit processors
> that do not support 80-bit extended, go for 64 bit
> double instead. If they all support it, use 80 bit, we
> want precision, not speed, because most 3D graphics
> do not need dates! :)
> 
> Conversion to and from double to extended is easy
> anyway as long as you stay within the safe range.
> When you go out of range you have just proven that
> we actually *need* 80 bits!

This attitude is what will make D a Intel / Windows only programming language - if D is going to be truely sucessful it must be able to support the majority of architectures.  Few processors support 80 bit extended precision floating point numbers,  and many (ie. RISC processors) do not even have a floating point capibility and emulate it using integer instructions if required.  Using a floating point format (especially the rubbish one that is IEEE 754) would only decrease the ease of porting which would lead to D being a wide spread langauge.

>> (Though the dates and up looking like Treky stardates - which should
>> appeal to geeks :-)
> 
> LOL! You got me, that's why I like it!  :)

I guess me being a B5 fan is why I do not :-)

The year is 2259 ... but how the %^&* are we going to represent it.

C       2002/3/28

"DrWhat?" <blackmarlin@nospam.asean-mail.com> wrote in message news:a7vmt7$t7i$1@digitaldaemon.com...

> >> (Though the dates and up looking like Treky stardates - which should
> >> appeal to geeks :-)
> >
> > LOL! You got me, that's why I like it!  :)
>
> I guess me being a B5 fan is why I do not :-)

I second that, being a B5 fan myself.
I guess ulong is just enough.

> The year is 2259 ... but how the %^&* are we going to represent it.

Nah, it's 2262! =)