Is there another class to process dates after 2038? (and before 1970)
Thanks.
Jean-Baptiste wrote:
Is there another class to process dates after 2038? (and before 1970)
Thanks.
Sorry.
I just found the Date class.
It looks much slower than Time class.
JB
Hi!
- Jean-Baptiste:
Is there another class to process dates after 2038? (and before
1970)
Just to point that out: We are very close to the middle of epoch
(saturday, don’t know the precise time by heart).
Josef ‘Jupp’ SCHUGT
···
–
http://oss.erdfunkstelle.de/ruby/ - German comp.lang.ruby-FAQ
http://rubyforge.org/users/jupp/ - Ruby projects at Rubyforge
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Germany 2004: To boldly spy where no GESTAPO / STASI has spied before
Saturday, 2004 January 10 13:37:04 UTC
···
On Wed, Jan 07, 2004 at 10:06:24AM +0900, Josef ‘Jupp’ SCHUGT wrote:
Just to point that out: We are very close to the middle of epoch
(saturday, don’t know the precise time by heart).
“Mark J. Reed” markjreed@mail.com wrote in message
···
On Wed, Jan 07, 2004 at 10:06:24AM +0900, Josef ‘Jupp’ SCHUGT wrote:
Just to point that out: We are very close to the middle of epoch
(saturday, don’t know the precise time by heart).Saturday, 2004 January 10 13:37:04 UTC
Please allow my ignorance: what is this all about? I thought epoch was just
a unit of time.
Did not know that it had a middle.
— shanko
Could someone tell me an elegant way to figure that out?
I’m trying to figure out how the Time function works. I’m looking at the
ri documentation, but I haven’t figured out what it expects for input.
Is UTC the same as Greenwich Mean Time?
Cheers,
···
On Wed, Jan 07, 2004 at 10:36:42AM +0900, Mark J. Reed wrote:
Just to point that out: We are very close to the middle of epoch
(saturday, don’t know the precise time by heart).Saturday, 2004 January 10 13:37:04 UTC
–
Daniel Carrera | No trees were harmed in the generation of this e-mail.
PhD student. | A significant number of electrons were, however, severely
Math Dept. UMD | inconvenienced.
“Mark J. Reed” markjreed@mail.com wrote in message
Just to point that out: We are very close to the middle of epoch
(saturday, don’t know the precise time by heart).Saturday, 2004 January 10 13:37:04 UTC
Please allow my ignorance: what is this all about? I thought epoch was just
a unit of time.
Did not know that it had a middle.
Technically, an epoch is a point from which time is
measured; the UNIX epoch is Thursday, January 1, 1970 AD/CE at
midnight UTC/GMT in the Gregorian calendar.
What we were referring to is the fact that UNIX systems measure time using
a signed 32-bit integer representing the number of (non-leap) seconds since
the epoch. This limits the range of representable times; the latest
representable one is Tuesday, January 19, 2038 at 03:14:07 UTC,
which is 2^31-1 seconds from the epoch.
The midpoint of the representable range is this Saturday.
Presumably, by the time 2038 rolls around, UNIX systems will be using
64-bit integers for timekeeping, which will hold us for about half
a trillion years.
-Mark
Mon Jan 18 22:14:07 2038
Tue Jan 19 03:14:07 2038
···
On Tue, Jan 06, 2004 at 08:31:52PM -0600, Shashank Date wrote:
On Wed, Jan 07, 2004 at 10:06:24AM +0900, Josef ‘Jupp’ SCHUGT wrote:
— shanko
Shashank Date wrote:
“Mark J. Reed” markjreed@mail.com wrote in message
Just to point that out: We are very close to the middle of epoch
(saturday, don’t know the precise time by heart).Saturday, 2004 January 10 13:37:04 UTC
Please allow my ignorance: what is this all about? I thought epoch was just
a unit of time.
Did not know that it had a middle.
In general that is true.
They are talking about Unix time, which has its zero point
at Jan 1, 1970 midnight UTC. In a fixed number of bits
(umm, 32?), the number of seconds will “overflow” in the
year 2038.
Then, of course, civilization will plunge
into chaos. Elevators won’t work, planes will fall out of
the sky, and dogs and cats will sleep together.
Strangely the math isn’t making sense to me at the moment.
A billion seconds should be very roughly thirty years.
That’s 109 or roughly 227. The epoch is 68 years long.
Surely we’re not storing it in 28 bits. Someone show me
where I’m being stupid.
Hal
···
On Wed, Jan 07, 2004 at 10:06:24AM +0900, Josef ‘Jupp’ SCHUGT wrote:
Could someone tell me an elegant way to figure that out?
I’m trying to figure out how the Time function works. I’m looking at the
ri documentation, but I haven’t figured out what it expects for input.
Sorry to reply to my own post, but by trial and error I think I found it.
Time.at takes the number of seconds since the epoch, right?
So, to figure out the mid point of the Epoch I simply use:
Time.at(2**30).utc
=> Sat Jan 10 13:37:04 UTC 2004
Is UTC the same as Greenwich Mean Time?
I guess it must be. But Time doesn’t seem to have a ‘gmt’ method.
···
On Thu, Jan 08, 2004 at 03:24:52AM +0900, Daniel Carrera wrote:
–
Daniel Carrera | No trees were harmed in the generation of this e-mail.
PhD student. | A significant number of electrons were, however, severely
Math Dept. UMD | inconvenienced.
Daniel Carrera wrote:
Is UTC the same as Greenwich Mean Time?
For most purposes, yes. UTC is an acronym that equally mis-matches the
English phrase “Coordinated Universal Time” and its French translation.
It is close, but not identical, to GMT.
More information is available at
http://physics.nist.gov/GenInt/Time/world.html.
Steve
In article 20040107182446.GA1168@math.umd.edu,
Appologies for non-ruby content
Is UTC the same as Greenwich Mean Time?
see http://physics.nist.gov/GenInt/Time/world.html or
http://aa.usno.navy.mil/faq/docs/UT.html
Hope this helps,
Mike
···
Daniel Carrera dcarrera@math.umd.edu wrote:
mike@stok.co.uk | The “`Stok’ disclaimers” apply.
http://www.stok.co.uk/~mike/ | GPG PGP Key 1024D/059913DA
mike@exegenix.com | Fingerprint 0570 71CD 6790 7C28 3D60
http://www.exegenix.com/ | 75D2 9EC4 C1C0 0599 13DA
Hal Fulton wrote:
Strangely the math isn’t making sense to me at the moment.
A billion seconds should be very roughly thirty years.
That’s 109 or roughly 227. The epoch is 68 years long.
Surely we’re not storing it in 28 bits. Someone show me
where I’m being stupid.
Sorry to reply to myself. Of course, a billion ~= 230
((210)**3).
But then another factor of two should be sufficient to store
the date (31 bits).
The answer apparently is that Unix time with the sign bit
(was that always there?) can go backwards ~68 years also.
So in theory we should be able to represent dates roughly
back to 1902. And checking in irb, I see that this works.
Hmm, did I get this wrong in TRW ch 2?
Hal
A 32-bit integer can hold 2**32 = 4,294,967,296 values. In
the case of UNIX time_t, those values represent numbers of seconds;
4,294,967,296 seconds is 49,710.(2696)+ days or a bit over 136
years, so that’s the size of the representable range.
Now, if a 32-bit integer is treated as unsigned, its values are
interpreted as the numbers 0 through 4,294,967,295, which would
make the representable range 1970 through 2106. But, at least on
some platforms, time_t is treated as a signed value, meaning
it’s interpreted as having a value between -2,147,483,648 and
2,147,483,647. So the representable range stops at 2038, although
it does theoretically extend backward to 1902. Even there, though,
most apps only allow positive values even though the value is signed,
so the only reliably representable values are between 1970 and 2038.
And the midpoint of that range is this Saturday.
-Mark
···
On Wed, Jan 07, 2004 at 12:10:14PM +0900, Hal Fulton wrote:
Strangely the math isn’t making sense to me at the moment.
A billion seconds should be very roughly thirty years.
That’s 109 or roughly 227. The epoch is 68 years long.
Surely we’re not storing it in 28 bits. Someone show me
where I’m being stupid.
Sorry to reply to my own post, but by trial and error I think I found it.
Time.at takes the number of seconds since the epoch, right?
Right.
So, to figure out the mid point of the Epoch I simply use:
Time.at(2**30).utc
=> Sat Jan 10 13:37:04 UTC 2004
Yup! It surprises me the number of times as a sysadmin I needed to know
what real-world time a time_t value corresponded to; most things translate
and hide that from the user, but it kept cropping up. Before Ruby, I would
use something like this (e.g. to find out when the decimal representation
of the second count “rolled over” to 1,000,000,000 a couple years ago,
which was Sunday, September 9, 2001, at 01:46:40 UTC):
$ perl -e 'print scalar localtime 10**9,"\n"' # local time
$ perl -e 'print scalar gmtime 10**9,"\n"' # UTC
But now I use:
$ ruby -e 'puts Time.at(10**9)' # local time
$ ruby -e 'puts Time.at(10**9).utc' # UTC
Not only does it feed my growing preference for Ruby over Perl, it’s
even less typing.
Is UTC the same as Greenwich Mean Time?
Short answer: yes. Long answer: "no, but . . . "
See the links provided in the other answer for exhausting detail, but
the main practical difference is that prior sometime in the 1920s,
0 hours GMT was NOON rather than midnight (for the convenience of astronomers,
to keep the date from changing in the middle of their “workday”). So
when historical data - or new data about events long in the past - includes a
GMT timestamp, it’s not always which time the given hour is counted from.
Whereas UTC is defined to start at midnight no matter how far back in time you
use it. For instance, the first new moon of the Hebrew calendar era was
in the Julian calendar BCE 3761 October 6 at 20:50:20 UTC. Documents written
about the Hebrew calendar in the last century would be likely to label
that time 08:50:20 GMT, while documents written between World War II and
the Vietnam War, say, would label it 20:50:20 GMT. Unless you know when a
document was written, you don’t know what GMT means.
-Mark
···
On Thu, Jan 08, 2004 at 03:32:02AM +0900, Daniel Carrera wrote:
Not only does it feed my growing preference for Ruby over Perl, it’s
even less typing.
I do love Ruby. =)
Is UTC the same as Greenwich Mean Time?
Short answer: yes. Long answer: "no, but . . . "
Thanks.
UTC rocks. The other links were very interesting too.
I am definitely going to celebrate the 230th second after the epoch.
It’s not often that this happens. The last 230 seconds have been great
and eventful for Unix, and now Linux is positioned to carry on this proud
tradition. May the next 2**30 seconds be prosperous ones.
Happy epoch to everyone!
Cheers,
···
–
Daniel Carrera | No trees were harmed in the generation of this e-mail.
PhD student. | A significant number of electrons were, however, severely
Math Dept. UMD | inconvenienced.