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

> So because Unix got it wrong, we should continue to suffer?  :-) I like
the
> Julian cycles idea because it is consistant and doesn't need "negative dates".   But it is a small point.

You are never going to deal with the internal representation - well, almost.
=)
Most often you'll use functions like:

    long makeDate(int day, int month, int year);
    long dateDiff(long d1, long d2);
    ...

> One related comment.  If we are going to use a 64 bit value for the time, the base should be a unit time much smaller than milliseconds.
Microseconds
> at least, and probably nanoseconds.  There should be some minimal accuracy

64-bit integer is used to store both date and time. Will it be enough to hold large dates with microsecond resolution?

Stephen Fuld wrote:
> So because Unix got it wrong, we should continue to suffer?  :-) I like the
> Julian cycles idea because it is consistant and doesn't need "negative
> dates".   But it is a small point.

4713 BCE isn't the beginning of time. You _will_
need negative dates. Or rather, someone will --
albeit not necessarily with high precision.

> One related comment.  If we are going to use a 64 bit value for the time,
> the base should be a unit time much smaller than milliseconds.  Microseconds
> at least, and probably nanoseconds. 

64 bits isn't quite enough to specify billions of
years with billionths of seconds precision. It's
probably enough to handle almost every need, but
I'm inclined to use:

int64 	signed_seconds_since_epoch;
uint64          unsigned_fractional_seconds;

Or, looked at another way, a signed 64.64 fixed-
point, with the point at the seconds place.

I don't really care if Epoch is noon/1/1/4713BCE or
midnight/1/1/1970 or 10:23am/8/23/1969. Whatever's
convenient for one bunch of people (astronomers,
accountants, physicists, historians) will be inconvenient
for another bunch, but all you need to know is
what to add/subtract to convert.

-RB

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C9F8E94.8030001@estarcion.com...

> 64 bits isn't quite enough to specify billions of
> years with billionths of seconds precision. It's
> probably enough to handle almost every need, but
> I'm inclined to use:
>
> int64
> signed_seconds_since_epoch;
> uint64          unsigned_fractional_seconds;

A single uint is enough to hold any date in approximate range of 0-500000
years with microsecond precision. I guess it's pretty enough for any
exact date; yes, sometimes they say "it was in year 30,000,000 BC", but
it's not a date, it's just a year. So, for any practical purpose, I guess
this method fits. What will be the zero-point is not so important -
as you've stated, it's just the matter of adding/subtracting some
constant value...

Pavel Minayev wrote:
> A single uint is enough to hold any date in approximate range of 0-500000
> years with microsecond precision. I guess it's pretty enough for any
> exact date; yes, sometimes they say "it was in year 30,000,000 BC", but
> it's not a date, it's just a year. 

My point is that some people need bigger range, and other
people need more precision. If you want a single time
type in the language, it needs to cover both those needs,
otherwise someone is going to say "microseconds? bah!
I need nanoseconds!" or "millions of years? bah! I need
billions!", and 64 bits might not be enough.

-R

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C9FA0E2.4080000@estarcion.com...
> Pavel Minayev wrote:
> > A single uint is enough to hold any date in approximate range of
0-500000
> > years with microsecond precision. I guess it's pretty enough for any exact date; yes, sometimes they say "it was in year 30,000,000 BC", but it's not a date, it's just a year.
>
> My point is that some people need bigger range, and other
> people need more precision. If you want a single time
> type in the language, it needs to cover both those needs,
> otherwise someone is going to say "microseconds? bah!
> I need nanoseconds!" or "millions of years? bah! I need
> billions!", and 64 bits might not be enough.

A 64 bit signed int measured in milliseconds will handle time for +- 285,000 years. That's enough for system programming use. I agree it will likely not be adequate for astronomers, but there should be no trouble adding a package that has time measured in astronomical units.

64 bit ints are nice because they are conveniently handled by the compiler.

Sometimes I need microsecond times - but for computing elapsed time for things like profiling, not for measuring calendar time. I think those are handled adequately by being separate.

In any case, it will be a typedef, and if the API for it is followed, there should be no trouble if someone upgrades to a 128 bit time or whatever.

"DrWhat?" <DrWhat@nospam.madscientist.co.uk> wrote in message
news:a7koqi$20lc$1@digitaldaemon.com...
<SNIP>
>
> A little info (copied from somewhere on the Internet many years ago -
sorry
> lost the URL and it probably no longer exists anyway)
>
> ---------------------

Guess what, it still exists...
You can't beat google  :)
http://www.faqs.org/faqs/astronomy/faq/part3/section-6.html
http://www.geocities.com/CapeCanaveral/Lab/7671/julian.htm

I like your idea by the way!

Has someone looked at OleDateTime? I believe it's
a 64 bit float? It represents the amount of days passed
since some moment in time. Parts of a day are
represented with the fractional part of the float, so 6
hours would translate to the number 0.25, 12 hours to
0.5, two days to 2.0 and 3 days and 18 hours to 3.75.

The advantage of this system is that it is very easy to extract either the date or the time part of a datetime. Also, calculations with precision in days do not need to divide the number.

D's more advanced version could use an extended. I
don't know what kind of range and precision that would
give, but I bet it's enormeous!


--
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:a7nr2a$2nes$1@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a7nj12$2jad$1@digitaldaemon.com...
> > "DrWhat?" <blackmarlin@nospam.asean-mail.com> wrote in message news:a7n7d3$2cv1$1@digitaldaemon.com...
> >
> > > A 64 bit count is a good idea but if we count from 1970 then how do we represent dates before then (ie. birthdays - some of which could be as early as 1880) - surely a proprietary format is not a good idea and
will
> > > decrease interoperability and negitive dates are not pleasant.  And
> >
> > We could use signed ints. Also, this is the format used by UNIX, I
> believe,
> > not something taken randomly.
>
> So because Unix got it wrong, we should continue to suffer?  :-) I like
the
> Julian cycles idea because it is consistant and doesn't need "negative dates".   But it is a small point.
>
> One related comment.  If we are going to use a 64 bit value for the time, the base should be a unit time much smaller than milliseconds.
Microseconds
> at least, and probably nanoseconds.  There should be some minimal accuracy specified (milliseconds is OK for the minimum, with the low order parts
set
> to zero), but we should allow a consistant mechanism for time handling for those systems that support a more precise clock.  Since we have to do a divide anyway if we want seconds, having to divide by a larger number
isn't
> a substantial price to pay for the seemlessnes of a single mechanism for high precision timers as well as more mundane uses.
>
> --
>  - Stephen Fuld
>    e-mail address disguised to prevent spam
>
>

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a7ntlu$2op0$1@digitaldaemon.com...
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7nr2a$2nes$1@digitaldaemon.com...
>
> > So because Unix got it wrong, we should continue to suffer?  :-) I like
> the
> > Julian cycles idea because it is consistant and doesn't need "negative dates".   But it is a small point.
>
> You are never going to deal with the internal representation - well,
almost.
> =)
> Most often you'll use functions like:
>
>     long makeDate(int day, int month, int year);
>     long dateDiff(long d1, long d2);
>     ...
>
> > One related comment.  If we are going to use a 64 bit value for the
time,
> > the base should be a unit time much smaller than milliseconds.
> Microseconds
> > at least, and probably nanoseconds.  There should be some minimal
accuracy
>
> 64-bit integer is used to store both date and time. Will it be enough to hold large dates with microsecond resolution?

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.

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

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C9FA0E2.4080000@estarcion.com...
> Pavel Minayev wrote:
> > A single uint is enough to hold any date in approximate range of
0-500000
> > years with microsecond precision. I guess it's pretty enough for any exact date; yes, sometimes they say "it was in year 30,000,000 BC", but it's not a date, it's just a year.
>
> My point is that some people need bigger range, and other
> people need more precision. If you want a single time
> type in the language, it needs to cover both those needs,
> otherwise someone is going to say "microseconds? bah!
> I need nanoseconds!" or "millions of years? bah! I need
> billions!", and 64 bits might not be enough.

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

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

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a7obqv$30n9$1@digitaldaemon.com...
> "DrWhat?" <DrWhat@nospam.madscientist.co.uk> wrote in message
> news:a7koqi$20lc$1@digitaldaemon.com...
> <SNIP>
> >
> > A little info (copied from somewhere on the Internet many years ago -
> sorry
> > lost the URL and it probably no longer exists anyway)
> >
> > ---------------------
>
> Guess what, it still exists...
> You can't beat google  :)
> http://www.faqs.org/faqs/astronomy/faq/part3/section-6.html
> http://www.geocities.com/CapeCanaveral/Lab/7671/julian.htm
>
> I like your idea by the way!
>
> Has someone looked at OleDateTime? I believe it's
> a 64 bit float? It represents the amount of days passed
> since some moment in time. Parts of a day are
> represented with the fractional part of the float, so 6
> hours would translate to the number 0.25, 12 hours to
> 0.5, two days to 2.0 and 3 days and 18 hours to 3.75.
>
> The advantage of this system is that it is very easy to extract either the date or the time part of a datetime. Also, calculations with precision in days do not need to divide the number.
>
> D's more advanced version could use an extended. I
> don't know what kind of range and precision that would
> give, but I bet it's enormeous!
>
>
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> __________________________________________
> Remove _XYZ from my address when replying by mail
>
>


So, how about it? An extended for a datetime?