Portable general timestamp format, not 2038-limited

[Martin Gregorie]

Re: Portable general timestamp format, not 2038-limited

Ilya Zakharevich wrote:

[A complimentary Cc of this posting was sent to
Martin Gregorie
<martin@see.sig .for.address>], who wrote in article <u1fdm4-32o.ln1@zoogz.g regorie.org>:

>Its in "A Short History of Time". Sorry I can't quote chapter or page,
>but a friend borrowed my copy and lent me Dawkins "Climbing Mount
>Improbable" before vanishing, never to be seen since. Not an equal
>exchange: I preferred ASHOT to CMI.

>

Oops - I should have written "A Brief History of Time". It was the first
edition, so I don't know if it was altered/edited out of later versions.

I would prefer a reference to a peer-reviewed paper. ;-)
>

Sure, but I don't think you'll find one. It was in a descriptive, rather
than rigorous, passage. But then, the book famously had only one
equation in it.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Hendrik van Rooyen]

Re: Portable general timestamp format, not 2038-limited

"greg" <greg@cosc.c... ry.ac.nzwrote:

>
Another thought: If the cosmologists ever decide if
and when the Big Crunch is going to happen, we may be
able to figure out once and for all how many bits we
need in the timestamp.
>

Unless of course, its all an oscillation - bang, crunch, bang, crunch,
as the cosmic engine ticks over...

But of course, cycles other than our own are kind of unreachable.

- Hendrik

[Ilya Zakharevich]

Re: Portable general timestamp format, not 2038-limited

[A complimentary Cc of this posting was sent to
Martin Gregorie
<martin@see.sig .for.address>], who wrote in article <qkvem4-slt.ln1@zoogz.g regorie.org>:

Its in "A Short History of Time". Sorry I can't quote chapter or page,
but a friend borrowed my copy and lent me Dawkins "Climbing Mount
Improbable" before vanishing, never to be seen since. Not an equal
exchange: I preferred ASHOT to CMI.

Oops - I should have written "A Brief History of Time". It was the first
edition, so I don't know if it was altered/edited out of later versions.

I would prefer a reference to a peer-reviewed paper. ;-)

Sure, but I don't think you'll find one. It was in a descriptive, rather
than rigorous, passage. But then, the book famously had only one
equation in it.

[I've heard about this book.]

My point is that attributing something to SH due to it appearing in
ABHoT is like attributing it to you since it was mentioned in your
post...

Hope this helps,
Ilya

[Michael Angelo Ravera]

Re: Portable general timestamp format, not 2038-limited

On Jun 22, 1:33 pm, James Harris <james.harri... @googlemail.com >
wrote:

I have a requirement to store timestamps in a database. Simple enough
you might think but finding a suitably general format is not easy. The
specifics are
>
1) subsecond resolution - milliseconds or, preferably, more detailed
2) not bounded by Unix timestamp 2038 limit
3) readable in Java
4) writable portably in Perl which seems to mean that 64-bit values
are out
5) readable and writable in Python
6) storable in a free database - Postgresql/MySQL
>
The formats provided by the two database systems are such as 8-byte or
12-byte values which, even if I could get Perl to work with I guess it
would be messy. Keeping to 32-bit values should give me portability
and be easy enough to work with without obscuring the program logic.
Since 32 bits of microseconds is less than 50 days I have to store two
32-bit values. How to split them? The option I favour at the moment is
to split days and parts of days like this:
>
a) store, as a 32-bit number, days since a virtual year zero (there is
no year zero in common era time <http://en.wikipedia.org/wiki/
Common_Era>). This allows over five million years plus and minus.
Still not completely general, I know.
b) store parts of days as another 32-bit value. Its range would have
to go to 86401 seconds - the number of seconds in a leap day. This
means each 'tick' would be around 21 microseconds. For regularity I
could make the ticks 25 microseconds so there would be 40,000 in a
second and 3,456,000,000 in a day; and, finally, the counter could
tick about 5 hours into the next day if not caught.
>
Any thoughts on a better way to do this? (Please reply-all. Thanks).

The best timestamp of which I am aware is microseconds since the
calendarical convergence back in 4713 BCE. This is the format used on
the old Tandem systems. Tandem chose to begin days at midnight, so
with some small tweaking, you can calculate the Julian day (by adding
12 hours) also, but you can choose to begin them at noon (as the
official Julian day does).

It is easily represented in 64 bits and won't overflow until well past
10000 CE. It also has the advantage of making for easy easy time
arithmetic and for reasonable conversion into any native format with
resolution no better than about 10 nanoseconds. You have to be
careful, if your resolution is better than that (you might overflow a
64-bit number if you try to go to your native format by multiplying
first), but it is quite useful.

The magic number for Unix-32 format is 210866760000000 000 (or that
divided by 1000 or 1000000 depending upon which way you go)

[Martin Gregorie]

Re: Portable general timestamp format, not 2038-limited

Ilya Zakharevich wrote:

My point is that attributing something to SH due to it appearing in
ABHoT is like attributing it to you since it was mentioned in your
post...
>

OK, so who should it be attributed to?


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Ilya Zakharevich]

Re: Portable general timestamp format, not 2038-limited

[A complimentary Cc of this posting was sent to
Martin Gregorie
<martin@see.sig .for.address>], who wrote in article <qj4gm4-9d5.ln1@zoogz.g regorie.org>:

Ilya Zakharevich wrote:

My point is that attributing something to SH due to it appearing in
ABHoT is like attributing it to you since it was mentioned in your
post...

OK, so who should it be attributed to?

*This* was my question; and with kitchentop book, one cannot expect to
find such an answer. If interested, Wiki looks like a good place to
look it up.

Given how obsolete this conjecture is (it contradicts the now known
data about uniformity of background radiation), I have no interest in
looking it up. :-(

Sorry,
Ilya

[Ben Finney]

Re: Portable general timestamp format, not 2038-limited

Ilya Zakharevich <nospam-abuse@ilyaz.org writes:

*This* was my question; and with kitchentop book, one cannot expect
to find such an answer. If interested, Wiki looks like a good place
to look it up.

I don't know what Wiki[0] has to do with it, but just to check:

<URL:http://c2.com/cgi/wiki?WhatIsNort hOfTheNorthPole >

Nope, can't find any existing page about it.


[0] Left unqualified, referring to a site named "Wiki" refers to *the*
Wiki, at <URL:http://c2.com/cgi/wiki>. If you mean some other
subsequent Wiki site, you'll need to be more specific.

--
\ "Consider the daffodil. And while you're doing that, I'll be |
`\ over here, looking through your stuff." -- Jack Handey |
_o__) |
Ben Finney

[Lew]

Re: Portable general timestamp format, not 2038-limited

Ben Finney wrote:

[0] Left unqualified, referring to a site named "Wiki" refers to *the*
Wiki, at <URL:http://c2.com/cgi/wiki>. If you mean some other
subsequent Wiki site, you'll need to be more specific.

I'm betting they meant
<http://en.wikipedia.or g/wiki/Main_Page>

or one of its non-English siblings.

--
Lew