Another Y2K!
Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: Another Y2K!

  1. #1

    Another Y2K!

    One of my friends sent this across. it really works. but don't try it unless u know how to change the date settings in BIOS.My network applications all crashed.

    Interesting read, not sure about the authenticity of
    this though. Good Read

    *Year 2038. Again the replica of Y2K*

    Note: This is just for FYI only, Please Don't try
    this. This is true and if you do this then your
    network based applications will not work.

    The Year 2038 Problem

    1. login to yahoo messenger
    2. send instant message to anyone - fine its
    3. now, change your system date to 19-Jan-2038,
    03:14:07 AM or above
    4. Confirm weather your date is changed
    5. again send instant message to anyone...

    Your YM crashes....

    NOW * * *

    What is it?*

    Starting at GMT 03:14:07, Tuesday, January 19, 2038,
    It is expected to see lots of systems around the world
    breaking magnificently: satellites falling out of
    orbit, massive power outages (like the 2003 North
    American black out), hospital life support system
    failures, phone system interruptions, banking errors,
    etc. One second after this critical second, many of
    these systems will have wildly inaccurate date
    settings, producing all kinds of unpredictable
    consequences. In short, many of the dire predictions
    for the year 2000 are much more likely to actually
    occur in the year 2038! Consider the year 2000 just a
    dry run. In case you think we can sit on this issue
    for another 30 years before addressing it, consider
    that reports of temporal echoes of the 2038 problem
    are already starting to appear in future date
    calculations for mortgages and vital statistics!

    In the first month of the year 2038 C.E. many
    computers will encounter a date-related bug in their
    operating systems and/or in the applications they run.
    This can result in incorrect and wildly inaccurate
    dates being reported by the operating system and/or
    applications. The effect of this bug is hard to
    predict, because many applications are not prepared
    for the resulting "skip" in reported time anywhere
    from 1901 to a "broken record" repeat of the reported
    time at the second the bug occurs. Also, may make
    some small adjustment to the actual time the bug
    expresses itself. This bug to cause serious problems
    on many platforms, especially Unix and Unix-like
    platforms, because these systems will "run out of

    What causes it?

    Time_t is a data type used by C and C++ programs to
    represent dates and times internally. (Windows
    programmers out there might also recognize it as the
    basis for the CTime and CTimeSpan classes in MFC.)
    time_t is actually just an integer, a whole number,
    that counts the number of seconds since January 1,
    1970 at 12:00 AM Greenwich Mean Time. A time_t value
    of 0 would be 12:00:00 AM (exactly midnight )
    1-Jan-1970 , a time_t value of 1 would be 12:00:01 AM

    (one second after midnig ht) 1-Jan-1970 , etc..
    some example times and their exact time_t

    Date & time time_t representation

    1-Jan-1970, 12:00:00 AM GMT 0
    1-Jan-1970, 12:01:00 AM GMT 60
    1-Jan-1970, 01:00:00 AM GMT 3 600
    2-Jan-1970, 12:00:00 AM GMT 86 400
    1-Jan-1971, 12:00:00 AM GMT 31 536 000
    1-Jan-1972, 12:00:00 AM GMT 63 072 000
    1-Jan-2038, 12:00:00 AM GMT 2 145 916 800
    19-Jan-2038, 03:14:07 AM GMT 2 147 483 647

    By the year 2038, the time_t representation for the
    current time will be over 2 140 000 000. And that's
    the problem. A modern 32-bit computer stores a "signed
    integer" data type, such as time_t, in 32 bits. The
    first of these bits is used for the positive/negative
    sign of the integer, while the remaining 31 bits are
    used to store the number itself.

    The highest number these 31 data bits can store works
    out to exactly 2 147 483 647. A time_t value of this
    exact number, 2 147 483 647, represents Janu ary 19,
    2038, at 7 seconds past 3:14 AM Greenwich Mean Time.
    So, at 3:14:07 AM GMT on that fateful day, every
    time_t used in a 32-bit C or C++ program will reach
    its upper limit.

    One second later, on 19-January-2038 at 3:14:08 AM
    GMT , disaster strikes. When a signed integer reaches
    its maximum value and then gets incremented, it wraps
    around to its lowest possible negative value. This
    means a 32-bit signed integer, such as a time_t, set
    to its maximum value of 2 147 483 647 and then
    incremented by 1, will become -2 147 483 648. Note
    that "-" sign at the beginning of this large number. A
    time_t value of -2 147 483 648 would represent
    December 13, 1901 at 8:45:52 PM GMT.

    So, if all goes normally, 19-January-2038 will
    suddenly become 13-December-1901 in every time_t
    across the globe, and every date calculation based on
    this figure will go haywire. And it gets worse. Most
    of the support functions that use t he time_t data type
    cannot handle negative time_t values at all. They
    simply fail and return an error code.
    "If you haven't failed you haven't tried hard enough"

    Do not Limit your challenges
    But challenge your Limits

  2. #2
    Senior Member
    Join Date
    Apr 2002
    Dont take any notice of this chain mail spam none the less.
    By the sacred **** of the sacred psychedelic tibetan yeti ....We\'ll smoke the chinese out
    The 20th century pharoes have the slaves demanding work

  3. #3
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    United Kingdom: Bridlington
    prodikal old chap........................might I be dead by then?

  4. #4
    T̙͓̞̣̯ͦͭͅͅȂͧͭͧ̏̈͏̖̖Z̿ ͆̎̄
    Join Date
    Dec 2004
    If I'm alive in 2038 on Jan 19th at 3:14:07 to even care...that will be the miracle

  5. #5
    ok now i was looking for some serious replies. when i say that my messengers crashed, i mean it. Besides, i doubt this is spam coz it was sent by some friend of min who works in a software Company in India.


    I am not ridiculing you, I am just asking you to help me out.

  6. #6
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    United Kingdom: Bridlington
    Hey Panther~

    I am not ridiculing you, I am just asking you to help me out.
    What help do you require old chap?...............Sergeant Major: "Close ranks, fix...........wait for it, wait for it...BAYONETS "

    You will get some good help here

  7. #7
    Leftie Linux Lover the_JinX's Avatar
    Join Date
    Nov 2001
    Beverwijk Netherlands
    Yeah.. It is true.. 2038 is the next Y2K

    The best thing about this bug is it's nick name though.. Friday 13th Bug

    Tue Jan 19 03:14:07 2038 the ANSI C (32 bit signed time_t) integer will be exhausted by then and some computer clocks will fall back to Fri Dec 13 20:45:52 1901 (or possibly December 32, 1969 on some systems (I'm looking at SGI))

    A little google would have given you the same info: (first three hits on google for 2038)
    ASCII stupid question, get a stupid ANSI.
    When in Russia, pet a PETSCII.

    Get your ass over to SLAYRadio the best station for C64 Remixes !

  8. #8
    Hey thanx jink. that really helped. so i was not wrong then. kewl!

    Have any possible solutions been found to this?

    mayb i should search things myself...hehe

  9. #9
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    United Kingdom: Bridlington
    Hey Panther~

    I think that there is one around 2024.................hits AppleMacs?

  10. #10
    Senior Member
    Join Date
    Apr 2002
    The thing is, is it hype or speculation ?. I dont think it is worthy of a panic status as of yet it may be plausible like Y2K but we will just have to sit back grow old and wait and see

    nihil You have mod status doesnt that make you God now
    By the sacred **** of the sacred psychedelic tibetan yeti ....We\'ll smoke the chinese out
    The 20th century pharoes have the slaves demanding work

Posting Permissions

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