Pavel Minayev wrote:
> 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?

Time is time, why make a distinction?

If it meant that I had to remember one time API instead
of two, I'd be willing to spend an extra 64 bits per
time object in order to unify high-precision and
high-range time.

<here he goes again>

Given operator overloading, the 128-bit time class
could look like a first-class datatype, as well.

</here he goes again>

That said, two APIs isn't so much of a problem, and
some people might well want to save the space, so I'm
okay either way.

-RB

DrWhat? wrote:
>>So, how about it? An extended for a datetime?
>>
>>
> Two problems which I see,
>         1       converting time -> seconds is none trivial

seconds_into_the_day = fmod( days, 1.0 ) * 86400; // == 60*60*24

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CA364D3.2010105@estarcion.com...
> Pavel Minayev wrote:
> > 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?
>
> Time is time, why make a distinction?
>
> If it meant that I had to remember one time API instead
> of two, I'd be willing to spend an extra 64 bits per
> time object in order to unify high-precision and
> high-range time.

Yes.  Why do you (Pavel) think dates and timers are different things?  Let me give an example.  For a health insurance program, you might want to calculate the length of someones's stay in the hospital (in days).  This requires essentially subtracting the release date from the entry date and adding one day.  How is this a totally different thing from getting the duration of some program loop by subtracting the start time from the completion time?

Having "timers" and absolute date/time retrieval use the same interface simplifies things.  One fewer thing to learn.  That is the primary motivation for combining them.

As for taking up more space, I believe Walter was proposing using a single 64 bit quantity, which is what I agreed was the best solution.  The only difference was I proposed adding the bits for higher precision, which costs nothing (except some totally beyond the fringe date ranges) by essentially shifting the field left.  There was a quibble about the base starting date, but we agreed that was a quibble.

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

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

Where do we need the multiply?

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

// This should truncate dt into date, yielding 3.0;

DateTime time = dt - date;

// 3.25 - 3.0 = 0.25      // Represents 06:00u

We only need a multiply if we want to convert to
hours, minutes or seconds is it not?
If we use a longint, won't we need a divide?
Aren't divides more expensive than multiplies?
I am not claiming any of these things to be true,
I am really just asking, because this is what I
thought it was.
Also, why did Borland and MS both picked a 64
bit float if it would be that bad?

- Getting the date is a truncating assignment.
- Getting the time is a truncating assignment and a subtract.
- Getting both is a truncating assignment, a subtract and
  another assignment.
- Getting hours, seconds, minutes etc is a truncating assignment,
  a subtract and a multiply...That is not too expensive is it?


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

How are you going to avoid floating point operations if you use
a longint to represent elapsed microseconds? Won't you need to
divide to get seconds, minutes, hours etc?
I thought FPU operations were fast becoming as cheap as
fp-emulation operations?


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

You are right here...Then again, 1 day might be 23, 24 or
25 hours depending on daylight saving time and one year
might be 365 or 366 days depending on the leapyear.
If you have a solution that solves this, great! I just
reread the Julian cycle story, but isn't it also counting
days from a certain starting point?
If you are proposing to keep date and time separate,
then that might be a solution, but what is the real advantage
of that?

Usually when I use dates in my program I want to do things
like compare them and add or subtract them.
These operations benefit greatly from a format with date
and time stuffed together. It isn't all that much I want to
actually display them, and that is the only moment when it
really matters that there are leapyears, -hours and -seconds.
A conversion will do just fine then, and who cares if it is
slow, displaying information tends to be slow anyhow.

Also, when you think about it, what is the difference between a date and a time? Isn't a date just time measured in days, while time is time measured in parts of days?


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

Ah come on...This has got nothing to do with windows.
Open source is open source and algorithms are algorithms,
no matter on what system you are. I agree that MS achieved
'polluting' C with WinMain et al, but you should still be
able to read it... ;)


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

You are probably right...


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

I do not understand...
Are these systems not capable of handling a double or extended?
If they do, what is the difference with a date?
I think my attitude has got nothing to do with Windows or Intel,
but with old and new. I understand the need to support old
hardware up to a point, but in such a young language as D is,
I'd rather look forward and make sure we are forwards compatible
with the future. If 64-bit's float is too much to ask for too
many systems, that's it, you won't hear me about it again, but
I just find it hard to believe that there are that many systems
out there that do not support it. Could you name some examples?


>
> >> (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

Whatever the format, *please* make it big!
(So we can still use it in 2259 when people live to be
a thousand years old!)  :)


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

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7vtfk$10i4$1@digitaldaemon.com...

> Yes.  Why do you (Pavel) think dates and timers are different things?  Let

They aren't

> me give an example.  For a health insurance program, you might want to calculate the length of someones's stay in the hospital (in days).  This requires essentially subtracting the release date from the entry date and adding one day.  How is this a totally different thing from getting the duration of some program loop by subtracting the start time from the completion time?

Yep. Both will be uints. Only for program, you might want it to run with
nanosecond precision, while date would be measured in microseconds.
But you still find the delta with operator-.

Dates are different in a sense they denote some concrete moment.
Date can be converted to some human-readable format. On other
hand, timers are used to measure time elapsed from some arbitrary
moment that you define, so for example the dayOfWeek() function
would make sence on dates but not on timers. Timer is just a
raw counter, and thus one could use uint without any typedefs
(what functions would you expect to work with timers?).
Date, however, would be a typedef, so it could be overloaded
separately.

> As for taking up more space, I believe Walter was proposing using a single 64 bit quantity, which is what I agreed was the best solution.  The only difference was I proposed adding the bits for higher precision, which
costs

So what is the suggested precision? Nanoseconds? Or microseconds?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a800hs$12dg$1@digitaldaemon.com...
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7vtfk$10i4$1@digitaldaemon.com...
>
> > Yes.  Why do you (Pavel) think dates and timers are different things?
Let
>
> They aren't
>
> > me give an example.  For a health insurance program, you might want to calculate the length of someones's stay in the hospital (in days).  This requires essentially subtracting the release date from the entry date
and
> > adding one day.  How is this a totally different thing from getting the duration of some program loop by subtracting the start time from the completion time?
>
> Yep. Both will be uints. Only for program, you might want it to run with
> nanosecond precision, while date would be measured in microseconds.
> But you still find the delta with operator-.
>
> Dates are different in a sense they denote some concrete moment.
> Date can be converted to some human-readable format. On other
> hand, timers are used to measure time elapsed from some arbitrary
> moment that you define, so for example the dayOfWeek() function
> would make sence on dates but not on timers. Timer is just a
> raw counter, and thus one could use uint without any typedefs
> (what functions would you expect to work with timers?).
> Date, however, would be a typedef, so it could be overloaded
> separately.
>
> > As for taking up more space, I believe Walter was proposing using a
single
> > 64 bit quantity, which is what I agreed was the best solution.  The only difference was I proposed adding the bits for higher precision, which
> costs
>
> So what is the suggested precision? Nanoseconds? Or microseconds?

If you are willing to live with a range of about 580 years, then nanoseconds.  However, there are a number of people who feel that is insufficient (I think it is OK, but I can see their point), in which case microseconds precision with a range of 580,000 years is still a better solution than what Walter originally proposed (millisecond resolution) and is probably the best compromise.  The extra precision you get by going from milliseconds to microseconds is essentially free if you use a 64 bit int for the value.  If, as some prefer, but a separate question, we kept time in a separate 64 bit value from date, then nanosecond precision (and even more precise, but that seems to be to be guilding the lilly) is free and thus should IMHO be adopted.

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

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a7vvc1$11or$1@digitaldaemon.com...
>
> "DrWhat?" <blackmarlin@nospam.asean-mail.com> wrote in message news:a7vmt7$t7i$1@digitaldaemon.com...
> > 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.
>
> Where do we need the multiply?
>
> DateTime dt = 3.25;
> DateTime date = (long) dt;
>
> // This should truncate dt into date, yielding 3.0;
>
> DateTime time = dt - date;
>
> // 3.25 - 3.0 = 0.25      // Represents 06:00u
>
> We only need a multiply if we want to convert to
> hours, minutes or seconds is it not?
> If we use a longint, won't we need a divide?
> Aren't divides more expensive than multiplies?
> I am not claiming any of these things to be true,
> I am really just asking, because this is what I
> thought it was.
> Also, why did Borland and MS both picked a 64
> bit float if it would be that bad?

Because they were not at all concerned with being able to run on systems that didn't have floating point support.  If D is successfull, it will get used in a lot of embedded applications where floating point support in hardware just isn't there.  We should not lightly write off these types of systems for a small benefit.



>
> - Getting the date is a truncating assignment.
> - Getting the time is a truncating assignment and a subtract.
> - Getting both is a truncating assignment, a subtract and
>   another assignment.
> - Getting hours, seconds, minutes etc is a truncating assignment,
>   a subtract and a multiply...That is not too expensive is it?
>
>
> > 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.
>
> How are you going to avoid floating point operations if you use a longint to represent elapsed microseconds? Won't you need to divide to get seconds, minutes, hours etc?

You have to do a divide, but not a floating point divide.  Many CPUs support integer divide instructions, or at least hardware assist for divide instructions.

> I thought FPU operations were fast becoming as cheap as fp-emulation operations?

No.  And again, many embedded systems have no need for floating point at all.  They would be reluctant to include a floating point emulation package just to be able to handle dates and times.

Just to remind people, the number of CPUs sold for embedded applications *far* exceeds the number sold for desktop and server applications.

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

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

> If you are willing to live with a range of about 580 years, then nanoseconds.  However, there are a number of people who feel that is insufficient (I think it is OK, but I can see their point), in which case microseconds precision with a range of 580,000 years is still a better solution than what Walter originally proposed (millisecond resolution) and is probably the best compromise.

I agree. Microsecond precision gives wide range of dates, and is enough for most practical timing purposes.

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a811kv$1jut$2@digitaldaemon.com...
> No.  And again, many embedded systems have no need for floating point at all.  They would be reluctant to include a floating point emulation
package
> just to be able to handle dates and times.
> Just to remind people, the number of CPUs sold for embedded applications
> *far* exceeds the number sold for desktop and server applications.

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.

I know about the ole floating point date format, but I can't see any superiority in using floats for time. I just see losing precision as the exponent bits take away from the precision. Conversions from 64 bit int time to 64 bit float time is trivial, anyway, it's just a divide and an add.

"Walter" <walter@digitalmars.com> wrote in message news:a826te$69l$1@digitaldaemon.com...
>
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a811kv$1jut$2@digitaldaemon.com...
> > No.  And again, many embedded systems have no need for floating point at all.  They would be reluctant to include a floating point emulation
> package
> > just to be able to handle dates and times.
> > Just to remind people, the number of CPUs sold for embedded applications
> > *far* exceeds the number sold for desktop and server applications.
>
> 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.
>
> I know about the ole floating point date format, but I can't see any superiority in using floats for time. I just see losing precision as the exponent bits take away from the precision. Conversions from 64 bit int
time
> to 64 bit float time is trivial, anyway, it's just a divide and an add.
>
>

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


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