Professional Web Applications Themes

class Time doesn't pass year 2038? - Ruby

Is there another class to process dates after 2038? (and before 1970) Thanks....

  1. #1

    Default class Time doesn't pass year 2038?


    Is there another class to process dates after 2038? (and before 1970)

    Thanks.
    Jean-Baptiste Guest

  2. #2

    Default Re: class Time doesn't pass year 2038?

    Jean-Baptiste wrote:
     

    Sorry.
    I just found the Date class.

    It looks much slower than Time class.

    JB
    Jean-Baptiste Guest

  3. #3

    Default Re: class Time doesn't pass year 2038?

    Hi!

    * Jean-Baptiste: 

    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


    Josef Guest

  4. #4

    Default Re: class Time doesn't pass year 2038?

    On Wed, Jan 07, 2004 at 10:06:24AM +0900, Josef 'Jupp' SCHUGT wrote: 

    Saturday, 2004 January 10 13:37:04 UTC

    :)
    Mark Guest

  5. #5

    Default Re: class Time doesn't pass year 2038?


    "Mark J. Reed" <com> wrote in message 
    >
    > Saturday, 2004 January 10 13:37:04 UTC[/ref]

    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


    Shashank Guest

  6. #6

    Default Re: class Time doesn't pass year 2038?

    On Tue, Jan 06, 2004 at 08:31:52PM -0600, Shashank Date wrote: 
    > >
    > > Saturday, 2004 January 10 13:37:04 UTC[/ref]
    >
    > 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. :-)[/ref]

    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

     
    Mark Guest

  7. #7

    Default Re: class Time doesn't pass year 2038?

    Shashank Date wrote: 
    >>
    >>Saturday, 2004 January 10 13:37:04 UTC[/ref]
    >
    >
    > 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. :-)[/ref]

    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.

    <joke type="y2k">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.</joke>

    Strangely the math isn't making sense to me at the moment.

    A billion seconds should be very roughly thirty years.
    That's 10**9 or roughly 2**27. The epoch is 68 years long.
    Surely we're not storing it in 28 bits. Someone show me
    where I'm being stupid.



    Hal


    Hal Guest

  8. #8

    Default Re: class Time doesn't pass year 2038?

    Hal Fulton wrote: 

    Sorry to reply to myself. Of course, a billion ~= 2**30
    ((2**10)**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



    Hal Guest

  9. #9

    Default Re: class Time doesn't pass year 2038?

    On Wed, Jan 07, 2004 at 12:10:14PM +0900, Hal Fulton wrote: 

    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
    Mark Guest

  10. #10

    Default Re: class Time doesn't pass year 2038?

    On Wed, Jan 07, 2004 at 10:36:42AM +0900, Mark J. Reed wrote: 
    >
    > Saturday, 2004 January 10 13:37:04 UTC
    >
    > :)[/ref]


    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 doentation, but I haven't figured out what it expects for input.

    Is UTC the same as Greenwich Mean Time?

    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.


    Daniel Guest

  11. #11

    Default Re: class Time doesn't pass year 2038?

    On Thu, Jan 08, 2004 at 03:24:52AM +0900, Daniel Carrera wrote:
     

    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:
     [/ref]
    => Sat Jan 10 13:37:04 UTC 2004

     

    I guess it must be. But Time doesn't seem to have a 'gmt' method.


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

  12. #12

    Default Re: class Time doesn't pass year 2038?

    In article <umd.edu>,
    Daniel Carrera <umd.edu> wrote:

    Appologies for non-ruby content
     

    see http://physics.nist.gov/GenInt/Time/world.html or
    http://aa.usno.navy.mil/faq/docs/UT.html

    Hope this helps,

    Mike
    --
    co.uk | The "`Stok' disclaimers" apply.
    http://www.stok.co.uk/~mike/ | GPG PGP Key 1024D/059913DA
    com | Fingerprint 0570 71CD 6790 7C28 3D60
    http://www.exegenix.com/ | 75D2 9EC4 C1C0 0599 13DA
    Mike Guest

  13. #13

    Default Re: class Time doesn't pass year 2038?

    Daniel Carrera wrote: 

    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


    Steven Guest

  14. #14

    Default Re: class Time doesn't pass year 2038?

    On Thu, Jan 08, 2004 at 03:32:02AM +0900, Daniel Carrera wrote: 

    Right.
     [/ref]
    > => Sat Jan 10 13:37:04 UTC 2004[/ref]

    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. :)
     [/ref]

    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. Doents written
    about the Hebrew calendar in the last century would be likely to label
    that time 08:50:20 GMT, while doents written between World War II and
    the Vietnam War, say, would label it 20:50:20 GMT. Unless you know when a
    doent was written, you don't know what GMT means.

    -Mark
    Mark Guest

  15. #15

    Default Re: class Time doesn't pass year 2038?

     

    I do love Ruby. =)
     [/ref]
    >
    > Short answer: yes. Long answer: "no, but . . . " :)[/ref]

    Thanks.
    UTC rocks. The other links were very interesting too.

    I am definitely going to celebrate the 2**30th second after the epoch.
    It's not often that this happens. The last 2**30 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.


    Daniel Guest

Similar Threads

  1. ioError 2038 on MAC os
    By rainier1234 in forum Macromedia Flex General Discussion
    Replies: 0
    Last Post: April 5th, 07:04 PM
  2. Replies: 0
    Last Post: September 7th, 06:53 PM
  3. OT: It's that time of year again ...
    By james_b in forum Ruby
    Replies: 12
    Last Post: July 13th, 01:53 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139