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 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 or one of its non-English

Re: Portable general timestamp format, not 2038-limited

Ilya Zakharevich <[EMAIL PROTECTED]> 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: http://c2.com/cgi/wiki?Wh

Re: Portable general timestamp format, not 2038-limited

[A complimentary Cc of this posting was sent to Martin Gregorie <[EMAIL PROTECTED]>], who wrote in article <[EMAIL PROTECTED]>: > 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 >

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 | -- http://mail.p

Re: Portable general timestamp format, not 2038-limited

On Jun 22, 1:33 pm, James Harris <[EMAIL PROTECTED]> 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)

Re: Portable general timestamp format, not 2038-limited

[A complimentary Cc of this posting was sent to Martin Gregorie <[EMAIL PROTECTED]>], who wrote in article <[EMAIL PROTECTED]>: > >> 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" befo

Re: Portable general timestamp format, not 2038-limited

"greg" <[EMAIL PROTECTED]> wrote: > > 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, crun

Re: Portable general timestamp format, not 2038-limited

Ilya Zakharevich wrote: > [A complimentary Cc of this posting was sent to > Martin Gregorie > <[EMAIL PROTECTED]>], who wrote in article <[EMAIL PROTECTED]>: >> 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 Mo

Re: Portable general timestamp format, not 2038-limited

[A complimentary Cc of this posting was sent to Martin Gregorie <[EMAIL PROTECTED]>], who wrote in article <[EMAIL PROTECTED]>: > >> If Stephen Hawking is right, the shape of the universe > >> is such that there isn't any time "before" the big bang > >> at all. It's like asking what's north of the

Re: Portable general timestamp format, not 2038-limited

(Absolutely off topic!) En Mon, 09 Jul 2007 15:50:58 -0300, Steve Holden <[EMAIL PROTECTED]> escribió: > Brunel, of course, being an original, built his system with a wider > inter-rail gap, and passengers commented on the smoother ride they got. > But standardization wars aren't new, and IKB l

Re: Portable general timestamp format, not 2038-limited

Ilya Zakharevich wrote: > [A complimentary Cc of this posting was sent to > greg > <[EMAIL PROTECTED]>], who wrote in article <[EMAIL PROTECTED]>: >> Ilya Zakharevich wrote: >>> In pedantic mode: negative timestamps make sense with Big Bang as the >>> epoch as well. (AFAIU, the current way of thi

Re: Portable general timestamp format, not 2038-limited

[A complimentary Cc of this posting was sent to greg <[EMAIL PROTECTED]>], who wrote in article <[EMAIL PROTECTED]>: > Ilya Zakharevich wrote: > > In pedantic mode: negative timestamps make sense with Big Bang as the > > epoch as well. (AFAIU, the current way of thinking is that it was > > "just

Re: Portable general timestamp format, not 2038-limited

Ilya Zakharevich wrote: > In pedantic mode: negative timestamps make sense with Big Bang as the > epoch as well. (AFAIU, the current way of thinking is that it was > "just too hot" before the big bang, it is not that "there was > nothing".) If Stephen Hawking is right, the shape of the universe i

Re: Portable general timestamp format, not 2038-limited

Gabriel Genellina wrote: > En Thu, 05 Jul 2007 17:57:32 -0300, Wojtek <[EMAIL PROTECTED]> escribió: > >> Note: Since I am using the year as a "magic number", some of you >> may think that I am repeating the Y2K problem. Hey, if my application >> is still being used in the year 9998 I am not b

Re: Portable general timestamp format, not 2038-limited

En Thu, 05 Jul 2007 17:57:32 -0300, Wojtek <[EMAIL PROTECTED]> escribió: > Note: Since I am using the year as a "magic number", some of you > may think that I am repeating the Y2K problem. Hey, if my application > is still being used in the year 9998 I am not being paid nearly > enough... I

Re: Portable general timestamp format, not 2038-limited

James Harris 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 > > 2) not bounded by Unix timestamp 2038 limit I use the Java Calendar class for storing dates, which as I understa

Re: Portable general timestamp format, not 2038-limited

[A complimentary Cc of this posting was sent to James Harris <[EMAIL PROTECTED]>], who wrote in article <[EMAIL PROTECTED]>: > On 5 Jul, 02:53, greg <[EMAIL PROTECTED]> wrote: > > James Harris wrote: > > > With that the time would range to +/- 9000 > > > quintillion years (18 digits) > > > > Use t

Re: Portable general timestamp format, not 2038-limited

On 5 Jul, 08:46, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > On Wed, 04 Jul 2007 22:12:46 -0400, Roy Smith <[EMAIL PROTECTED]> declaimed > the following in comp.lang.python: > > > Astronomers use Julian Date (http://en.wikipedia.org/wiki/Julian_date) for > > calculations like this. It's a widel

Re: Portable general timestamp format, not 2038-limited

On 5 Jul, 02:53, greg <[EMAIL PROTECTED]> wrote: > James Harris wrote: > > With that the time would range to +/- 9000 > > quintillion years (18 digits) > > Use the Big Bang as the epoch, and you won't have > to worry about negative timestamps. Good idea if only they didn't keep shifting the femtos

Re: Portable general timestamp format, not 2038-limited

ames Harris <[EMAIL PROTECTED]> 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

Re: Portable general timestamp format, not 2038-limited

James Harris wrote: > With that the time would range to +/- 9000 > quintillion years (18 digits) Use the Big Bang as the epoch, and you won't have to worry about negative timestamps. -- Greg -- http://mail.python.org/mailman/listinfo/python-list

Re: Portable general timestamp format, not 2038-limited

On 4 Jul, 22:18, "Peter J. Holzer" <[EMAIL PROTECTED]> wrote: ... > But it really doesn't matter much. If you ignore leap seconds, using > days instead of seconds is just a constant factor (in fact, the unix > timestamp ignores leap seconds, too, so it's always a constant factor). > You can't repre

Re: Portable general timestamp format, not 2038-limited

On 2007-07-04 18:46, James Harris <[EMAIL PROTECTED]> wrote: > On 1 Jul, 15:11, "Peter J. Holzer" <[EMAIL PROTECTED]> wrote: > ... >> Stick to unix timestamps but store them as a double precision floating >> point number. The 53 bit mantissa gives you currently a resolution of >> about 200 ns, slow

Re: Portable general timestamp format, not 2038-limited

On 3 Jul, 06:12, Scott David Daniels <[EMAIL PROTECTED]> wrote: ... > Inspired format: > Days since a some standard date (the TAI date may be a good such > date) expressed as fixed point 64-bit (32-bit day part, 32-bit > day-fraction part) or floating point (using Intel's double-precision, > f

Re: Portable general timestamp format, not 2038-limited

On 1 Jul, 15:11, "Peter J. Holzer" <[EMAIL PROTECTED]> wrote: ... > Stick to unix timestamps but store them as a double precision floating > point number. The 53 bit mantissa gives you currently a resolution of > about 200 ns, slowly deteriorating (you will hit ms resolution in about > 280,000 year

Re: Portable general timestamp format, not 2038-limited

CBFalconer <[EMAIL PROTECTED]> writes: > "Peter J. Holzer" wrote: > > Hardly. That hasn't been in use for over 35 years (according to > > Wikipedia). > > I am glad to see you depend on absolutely reliable sources. Wikipedia is not an absolutely reliable source. I know of no "absolutely resliable

Re: Portable general timestamp format, not 2038-limited

Peter J. Holzer said: > It is possible that the observatory at Greenwich still keeps and > announces GMT, but it has no practical importance anymore. Certainly > what everybody (except specialists in the field) means when they talk > about "GMT" is UTC. I am not a specialist in the field. When

Re: Portable general timestamp format, not 2038-limited

On 2007-07-04 00:14, Dr.Ruud <[EMAIL PROTECTED]> wrote: > Peter J. Holzer schreef: >> Since a day with a leap second has 86401 seconds (or 86399, but that >> hasn't happened yet) > > Many systems allow a seconds value of 0..61, so minutes (actually > months) with two leap seconds are foreseen. Tha

Re: Portable general timestamp format, not 2038-limited

On 2007-07-03 23:15, CBFalconer <[EMAIL PROTECTED]> wrote: > "Peter J. Holzer" wrote: >> Richard Heathfield <[EMAIL PROTECTED]> wrote: >> > ... snip ... >> >>> In that case, the obvious choice is Greenwich Mean Time. :-) >> >> Hardly. That hasn't been in use for over 35 years (according to >> Wik

Re: Portable general timestamp format, not 2038-limited

Peter J. Holzer schreef: > Since a day with a leap second has 86401 seconds (or 86399, but that > hasn't happened yet) Many systems allow a seconds value of 0..61, so minutes (actually months) with two leap seconds are foreseen. A leap second may be introduced at the end of any month, the prefer

Re: Portable general timestamp format, not 2038-limited

"Peter J. Holzer" wrote: > Richard Heathfield <[EMAIL PROTECTED]> wrote: > ... snip ... > >> In that case, the obvious choice is Greenwich Mean Time. :-) > > Hardly. That hasn't been in use for over 35 years (according to > Wikipedia). I am glad to see you depend on absolutely reliable sources.

Re: Portable general timestamp format, not 2038-limited

On Jul 3, 1:10 am, Paul Rubin wrote: > Well, if you're trying to pick just one timestamp standard, I'd say > you're better off using a worldwide one rather than a national one, no > matter how the bureaucracies work. TAI is derived from atomic clocks > all over the world

Re: Portable general timestamp format, not 2038-limited

Peter J. Holzer said: > On 2007-07-03 08:57, Richard Heathfield <[EMAIL PROTECTED]> wrote: >> Paul Rubin said: >>> [EMAIL PROTECTED] writes: As for the primacy of UTC vs. TAI, this is the classical chicken and egg problem. The bureaucratic reality is opposed to the physical re

Re: Portable general timestamp format, not 2038-limited

On 2007-07-03 08:57, Richard Heathfield <[EMAIL PROTECTED]> wrote: > Paul Rubin said: >> [EMAIL PROTECTED] writes: >>> As for the primacy of UTC vs. TAI, this is the classical chicken and >>> egg problem. The bureaucratic reality is opposed to the physical >>> reality. >> >> Well, if you're tryin

Re: Portable general timestamp format, not 2038-limited

Peter J. Holzer wrote: > On 2007-07-03 05:12, Scott David Daniels <[EMAIL PROTECTED]> wrote: >> TOPS-20 did an interesting format which suggest an interesting variant: >> Tops-20: 36-bit (the machine word size) fixed-bit representation >>of days since a given moment (the first

Re: Portable general timestamp format, not 2038-limited

Paul Rubin said: > [EMAIL PROTECTED] writes: >> As for the primacy of UTC vs. TAI, this is the classical chicken and >> egg problem. The bureaucratic reality is opposed to the physical >> reality. > > Well, if you're trying to pick just one timestamp standard, I'd say > you're better off using a

Re: Portable general timestamp format, not 2038-limited

[EMAIL PROTECTED] writes: > As for the primacy of UTC vs. TAI, this is the classical chicken and > egg problem. The bureaucratic reality is opposed to the physical > reality. Well, if you're trying to pick just one timestamp standard, I'd say you're better off using a worldwide one rather than a

Re: Portable general timestamp format, not 2038-limited

On 2007-07-03 05:12, Scott David Daniels <[EMAIL PROTECTED]> wrote: > Peter J. Holzer wrote: >> On 2007-06-22 20:33, James Harris <[EMAIL PROTECTED]> wrote: >>> I have a requirement to store timestamps in a database. Simple enough >>> you might think but finding a suitably general format is not eas

Re: Portable general timestamp format, not 2038-limited

Peter J. Holzer wrote: > On 2007-06-22 20:33, James Harris <[EMAIL PROTECTED]> 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,

Re: Portable general timestamp format, not 2038-limited

Martin Gregorie wrote: > Roedy Green wrote: >> >> To add to the confusion you have GPS, Loran and Julian day also used >> as scientific times. > > > GPS time is UTC time No it isn't. GPS has never introduced a leap second, and is still on uncorrected UTC-as-of-1980. However, the GPS signal also

Re: Portable general timestamp format, not 2038-limited

Martin Gregorie <[EMAIL PROTECTED]> writes: > I've never seen Julian time used outside the world of IBM > mainframes. I'd be interested to know who else uses it. Systems which need to perform date+time computations into the past. One advantage of Julian time is that it ignores the "1 BC was immed

Re: Portable general timestamp format, not 2038-limited

Dennis Lee Bieber <[EMAIL PROTECTED]> writes: > What is not mentioned is that, as part of the data stream picked up > by GPS receivers, is a term specifying the "correction factor" between > GPS and UTC; so receivers can display UTC time. Oh yes, good point, the article ought to mention that

Re: Portable general timestamp format, not 2038-limited

Roedy Green wrote: > On Sun, 01 Jul 2007 17:47:36 +0100, Martin Gregorie > <[EMAIL PROTECTED]> wrote, quoted or indirectly quoted > someone who said : > >> GPS time is UTC time and I'd assume the same is true for Loran. > > not according to this site that has clocks running on all three. > They a

Re: Portable general timestamp format, not 2038-limited

Roedy Green wrote: > On 25 Jun 2007 18:46:25 -0700, Paul Rubin > ... snip ... > >> TAI really does seem like the most absolute--if you are a user >> in orbit or on Mars, then UTC timestamps will seem pretty >> meaningless and artificial. > > According to Einstein all time is local time, so perhap

Re: Portable general timestamp format, not 2038-limited

On Sun, 01 Jul 2007 17:47:36 +0100, Martin Gregorie <[EMAIL PROTECTED]> wrote, quoted or indirectly quoted someone who said : >GPS time is UTC time and I'd assume the same is true for Loran. not according to this site that has clocks running on all three. They are out slightly. http://www.leaps

Re: Portable general timestamp format, not 2038-limited

Martin Gregorie <[EMAIL PROTECTED]> writes: > GPS time is UTC time According to Wikipedia, While most clocks are synchronized to Coordinated Universal Time (UTC), the Atomic clocks on the satellites are set to GPS time. The difference is that GPS time is not corrected to match the r

Re: Portable general timestamp format, not 2038-limited

Roedy Green wrote: > On Tue, 26 Jun 2007 13:04:50 +0100, Martin Gregorie > <[EMAIL PROTECTED]> wrote, quoted or indirectly quoted > someone who said : > >> TAI? Care to provide a reference? > > see http://mindprod.com/jgloss/tai.html > Thanks. Your list of NTP servers on http://mindprod.com/jgl

Re: Portable general timestamp format, not 2038-limited

Roedy Green wrote: > > To add to the confusion you have GPS, Loran and Julian day also used > as scientific times. > GPS time is UTC time and I'd assume the same is true for Loran. Both are primarily for navigation and so are on Zulu time, which is another name for UTC. Zulu is the internationa

Re: Portable general timestamp format, not 2038-limited

On 25 Jun 2007 18:46:25 -0700, Paul Rubin wrote, quoted or indirectly quoted someone who said : >TAI really does seem like the most absolute--if you are a user in >orbit or on Mars, then UTC timestamps will seem pretty meaningless and >artificial. According to Einstein

Re: Portable general timestamp format, not 2038-limited

On Sunday 01 July 2007, Roedy Green wrote: > On 25 Jun 2007 18:46:25 -0700, Paul Rubin > wrote, quoted or indirectly quoted > > someone who said : > >You cannot accurately compute > >the number of seconds between Nixon's resignation and 1800 UTC today, > >unless you take

Re: Portable general timestamp format, not 2038-limited

On Tue, 26 Jun 2007 13:04:50 +0100, Martin Gregorie <[EMAIL PROTECTED]> wrote, quoted or indirectly quoted someone who said : >TAI? Care to provide a reference? see http://mindprod.com/jgloss/tai.html -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com -- http://mail.pyth

Re: Portable general timestamp format, not 2038-limited

Roedy Green <[EMAIL PROTECTED]> writes: > >You cannot accurately compute > >the number of seconds between Nixon's resignation and 1800 UTC today, > >unless you take into account the leap seconds have been occurred > >between then and now. > > There are two valid answers to those questions. In a c

Re: Portable general timestamp format, not 2038-limited

On 25 Jun 2007 18:46:25 -0700, Paul Rubin wrote, quoted or indirectly quoted someone who said : >You cannot accurately compute >the number of seconds between Nixon's resignation and 1800 UTC today, >unless you take into account the leap seconds have been occurred >betwee

Re: Portable general timestamp format, not 2038-limited

On 2007-06-22 20:33, James Harris <[EMAIL PROTECTED]> 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)

Re: Portable general timestamp format, not 2038-limited

On Jun 27, 10:51 pm, Paul Rubin wrote: > According to , UTC is derived from > TAI. According to , TAI is a proper time, but the very first section in the TAI discussion page cites a refereed paper by the

Re: Portable general timestamp format, not 2038-limited

On Jun 27, 10:51 pm, Paul Rubin wrote: > The difficulty/impossibility of computing intervals on UTC because of > leap seconds suggests TAI is a superior timestamp format. If you care about intervals you'd better keep timestamps in SI seconds since some zero time point (j

Re: Portable general timestamp format, not 2038-limited

[EMAIL PROTECTED] writes: > Keep in mind that TAI is not legal time anywhere. It is also not > practical, for the TAI now is not available until next month. If you mean they don't announce the average of the 350 atomic clocks til a month later, well swell, but you can get sub-microsecond accuracy

Re: Portable general timestamp format, not 2038-limited

On Jun 26, 2:17 pm, Paul Rubin wrote: > Martin Gregorie <[EMAIL PROTECTED]> writes: > > > Same one already given:http://cr.yp.to/proto/utctai.html > > > > Nope - you referencedleap seconds, not TAI and not that URL > > Oh whoops, I thought I put that url further up in th

Re: Portable general timestamp format, not 2038-limited

Martin Gregorie <[EMAIL PROTECTED]> writes: > > Same one already given: http://cr.yp.to/proto/utctai.html > > Nope - you referenced leap seconds, not TAI and not that URL Oh whoops, I thought I put that url further up in the thread. I remember grumbling to myself about having to look for it twice

Re: Portable general timestamp format, not 2038-limited

[EMAIL PROTECTED] wrote: > On Jun 25, 6:46 pm, Paul Rubin wrote: >> TAI really does seem like the most absolute--if you are a user in >> orbit or on Mars, then UTC timestamps will seem pretty meaningless and >> artificial. > > TAI makes sense for clocks on the surface of

Re: Portable general timestamp format, not 2038-limited

Paul Rubin wrote: > Same one already given: http://cr.yp.to/proto/utctai.html Nope - you referenced leap seconds, not TAI and not that URL Thanks for the reference, though. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list

Re: Portable general timestamp format, not 2038-limited

Martin Gregorie <[EMAIL PROTECTED]> writes: > I don't recall the OP mentioning time interval computability - just a > requirement for sub second accuracy timestamps. That Y2038 is an issue suggests the OP wants a timestamp format that is future-proof and that means it should be good for all plausi

Re: Portable general timestamp format, not 2038-limited

Paul Rubin wrote: > Martin Gregorie <[EMAIL PROTECTED]> writes: pretend the leap seconds never happened, just as Java does. >>> Which leaves you about 30 seconds out by now - smelly. >> Easy solution: always read Zulu time directly from a recognized >> real-time clock > > That's no good,

Re: Portable general timestamp format, not 2038-limited

On Jun 25, 6:46 pm, Paul Rubin wrote: > TAI really does seem like the most absolute--if you are a user in > orbit or on Mars, then UTC timestamps will seem pretty meaningless and > artificial. TAI makes sense for clocks on the surface of the earth (at least until ion tra

Re: Portable general timestamp format, not 2038-limited

Martin Gregorie <[EMAIL PROTECTED]> writes: > >> pretend the leap seconds never happened, just as Java does. > > Which leaves you about 30 seconds out by now - smelly. > Easy solution: always read Zulu time directly from a recognized > real-time clock That's no good, it doesn't let you accurat

Re: Portable general timestamp format, not 2038-limited

On 25 Jun, 02:14, [EMAIL PROTECTED] (Robert Maas, see http://tinyurl.com/uh3t) wrote: > > From: James Harris <[EMAIL PROTECTED]> > > I have a requirement to store timestamps in a database. ... > > 1) subsecond resolution - milliseconds or, preferably, more detailed > > How do you plan to deal with

Re: Portable general timestamp format, not 2038-limited

Steve O'Hara-Smith wrote: > On Mon, 25 Jun 2007 11:17:27 GMT > Roedy Green <[EMAIL PROTECTED]> wrote: > >> On Sun, 24 Jun 2007 18:14:08 -0700, [EMAIL PROTECTED] (Robert Maas, >> see http://tinyurl.com/uh3t) wrote, quoted or indirectly quoted >> someone who said : >> >>> - Stick to astronomical tim

Re: Portable general timestamp format, not 2038-limited

On Mon, 25 Jun 2007 11:17:27 GMT Roedy Green <[EMAIL PROTECTED]> wrote: > On Sun, 24 Jun 2007 18:14:08 -0700, [EMAIL PROTECTED] (Robert Maas, > see http://tinyurl.com/uh3t) wrote, quoted or indirectly quoted > someone who said : > > >- Stick to astronomical time, which is absolutely consistent bu

Re: Portable general timestamp format, not 2038-limited

On Sun, 24 Jun 2007 18:14:08 -0700, [EMAIL PROTECTED] (Robert Maas, see http://tinyurl.com/uh3t) wrote, quoted or indirectly quoted someone who said : >- Stick to astronomical time, which is absolutely consistent but > which drifts from legal time? depends what you are measuring. IF you are doi

Re: Portable general timestamp format, not 2038-limited

> From: James Harris <[EMAIL PROTECTED]> > I have a requirement to store timestamps in a database. ... > 1) subsecond resolution - milliseconds or, preferably, more detailed How do you plan to deal with leap seconds? - Stick to astronomical time, which is absolutely consistent but which drifts

Re: Portable general timestamp format, not 2038-limited

On Fri, 22 Jun 2007 13:33:04 -0700, James Harris <[EMAIL PROTECTED]> wrote, quoted or indirectly quoted someone who said : >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 see

Re: Portable general timestamp format, not 2038-limited

On Sat, 23 Jun 2007 13:37:14 -0700, James Harris <[EMAIL PROTECTED]> wrote: >On 22 Jun, 23:49, Roger Miller <[EMAIL PROTECTED]> wrote: >... >> My rule of thumb in situations like this is "When in doubt store it as >> text". The one format I am pretty sure we will still be able to deal >> with in

Re: Portable general timestamp format, not 2038-limited

On 22 Jun, 23:49, Roger Miller <[EMAIL PROTECTED]> wrote: ... > My rule of thumb in situations like this is "When in doubt store it as > text". The one format I am pretty sure we will still be able to deal > with in 2039. Interesting. I hadn't thought about using text. It would add to the storage

Re: Portable general timestamp format, not 2038-limited

James Harris <[EMAIL PROTECTED]> writes: > 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 > ... There are subtle

Re: Portable general timestamp format, not 2038-limited

On Jun 22, 10:33 am, James Harris <[EMAIL PROTECTED]> 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. > ... > Any thoughts on a better way to do this? (Please reply-all. Thanks). > > -- > James My

Re: Portable general timestamp format, not 2038-limited

James Harris wrote: > a) store, as a 32-bit number, days since a virtual year zero (there is > no year zero in common era time ). But according to the same article: > (It [year zero] is, however, used in the astronomical system and ISO 8601.) -- Lew --

Re: Portable general timestamp format, not 2038-limited

On Fri, 2007-06-22 at 13:33 -0700, James Harris 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