Year 2038 problem.

drunkbnu · 2017-09-21 20:21:42

19/01/2038 03:14:07 UTC

The date where all the Unix platforms working with 32-bit signed integers for time-stamps will stop working properly, due to the date being equal to the maximum positive value that can be stored on a 32-bit signed integer. Dates beyond 19/01/2038 03:14:07 UTC will cause the time_t integers to be stored as negative values, the cause of this being the change of the first bit, which on a signed integer, represents the sign.

This will cause all devices that make use of this type of integer to work with a date that starts at 13/12/1901 20:45:52 UTC, which might cause undefined behaviors on programs and file systems that make the use of time_t, but don't allow usage of dates on that range. Windows users might be careless about this topic since they won't be affected, but most of servers around the world use Unix platforms, and if they don't take action before this date they'll start to fail for everyone making use of them.

RavaTroll, SirJosh3917

Bimps · 2017-09-21 20:40:04

y2k

drunkbnu, Tomahawk, CommanderKitten, Kikikan, mrjawapa

MartenM · 2017-09-21 20:54:18

I think we will have figured out this problem by 2038.

Or maybe we are just lazy and we are going to just use this as new time (13/12/1901 20:45:52)

Zumza

drunkbnu · 2017-09-21 21:02:45

The only way to allow for a bigger time range is by changing the size of the time_t integer, which will cause a lot of conflicts with current internal functions shared by most of all Unix programs that make use of time-stamps, such as file systems and data-bases, and will break apps that make use of dates prior or beyond the range of dates allowed by the current time_t if it's structure gets changed.

Zumza · 2017-09-21 21:07:25

The real end of the world won't be predicted by anybody

LukeM · 2017-09-21 21:54:06

Zumza wrote:

The real end of the world won't be predicted by anybody

Well it probably will be, but not in this way

TaskManager · 2017-09-22 00:11:21

MartenM wrote:

I think we will have figured out this problem by 2038.

we already have, sort of

Wikipedia wrote:

Most operating systems designed to run on 64-bit hardware already use signed 64-bit time_t integers. Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now, at 15:30:08 UTC on Sunday, 4 December 292,277,026,596. The ability to make computations on dates is limited by the fact that tm_year uses a signed 32 bit integer value starting at 1900 for the year. This limits the year to a maximum of 2,147,485,547 (2,147,483,647 + 1900).

21 years is enough to switch to 64-bit hardware, right

hummerz5 · 2017-09-22 00:25:44

maxi123 wrote:

21 years is enough to switch to 64-bit hardware, right

but is 292 billion years enough to get away from 64-bit architectures?

some woman, drunkbnu, AlphaJon, LukeM, TaskManager, SirJosh3917, Kikikan

XxAtillaxX · 2017-09-22 02:47:13

hummerz5 wrote:

maxi123 wrote:
21 years is enough to switch to 64-bit hardware, right
but is 292 billion years enough to get away from 64-bit architectures?

just wait until the corporations start reserving huge chunks of seconds like they did with ipv4

hummerz5, Xfrogman43, Zumza, SirJosh3917

Anatoly · 2017-09-25 06:12:10

hummerz5 wrote:

maxi123 wrote:
21 years is enough to switch to 64-bit hardware, right
but is 292 billion years enough to get away from 64-bit architectures?

63* Only 63 Bits. The first bit is the +/- factor.

With that formula decimals were created or smt.

S - EXPONENT - MANTISSA. So in fact 64 bit numbers are not really 64.

LukeM · 2017-09-25 08:18:41

It's still called 64 bit, because 64 bits are used to store numbers, regardless of what each bit is specifically used for

Also, the max size of the number depends on its type
A double (what you explained) can store up to 2^53 - 1 until it starts to lose precision, as it has a 54 bit mantissa (which includes the sign bit)
Doubles can also store any number up to ^ times up to 2^(2^9 - 1) (or divided by 2^(2^9)), so really huge numbers, but these wouldn't be good enough to store the time as they would skip a lot of numbers in between values.

The time is usually stored as either a signed or unsigned integer, as if you can't use the exponent of doubles, you might as well use every bit you have. An unsigned integer can store up to 2^64 - 1 and a signed integer 2^63 - 1

P.S. Double is the C# name for a 64 bit floating point number

Ratburntro44, drunkbnu

Ratburntro44 · 2017-09-26 00:01:47

AnatolyEE wrote:

hummerz5 wrote:
maxi123 wrote:
21 years is enough to switch to 64-bit hardware, right
but is 292 billion years enough to get away from 64-bit architectures?
63* Only 63 Bits. The first bit is the +/- factor.
[...]

destroyer123 wrote:

[..]
and a signed integer 2^63 - 1

wow, it's almost as if someone was looking for something to "correct" rather than actually noticing a problem

soniiiety · 2017-09-26 00:33:33

the real end of the world is armageddon sorry to break to you jw.org search that now to find out more on HOW YOU! can survive into paradise plus we are in the last days the last days started at 1914 and we are so close to it

Pingohits

drunkbnu · 2017-09-26 01:01:53

AnatolyEE wrote:

hummerz5 wrote:
maxi123 wrote:
21 years is enough to switch to 64-bit hardware, right
but is 292 billion years enough to get away from 64-bit architectures?
63* Only 63 Bits. The first bit is the +/- factor.
https://habrastorage.org/getpro/habr/fo … fdcf97.svg
With that formula decimals were created or smt.
https://habrastorage.org/getpro/habr/po … e752d0.svg
S - EXPONENT - MANTISSA. So in fact 64 bit numbers are not really 64.

We're talking about the platform architectures, not the integer types.

rdash · 2017-09-27 20:57:36

It's the Epochalypse!

skullz17

Official Everybody Edits Forums

#1 2017-09-21 20:21:42, last edited by drunkbnu (2017-09-26 01:03:35)

Year 2038 problem.

19/01/2038 03:14:07 UTC

#2 2017-09-21 20:40:04

Re: Year 2038 problem.

#3 2017-09-21 20:54:18, last edited by MartenM (2017-09-21 20:55:25)

Re: Year 2038 problem.

#4 2017-09-21 21:02:45, last edited by drunkbnu (2017-09-21 21:05:05)

Re: Year 2038 problem.

#5 2017-09-21 21:07:25

Re: Year 2038 problem.

#6 2017-09-21 21:54:06

Re: Year 2038 problem.

#7 2017-09-22 00:11:21

Re: Year 2038 problem.

#8 2017-09-22 00:25:44

Re: Year 2038 problem.

#9 2017-09-22 02:47:13

Re: Year 2038 problem.

#10 2017-09-25 06:12:10

Re: Year 2038 problem.

#11 2017-09-25 08:18:41, last edited by LukeM (2017-09-25 08:24:18)

Re: Year 2038 problem.

#12 2017-09-26 00:01:47, last edited by Ratburntro44 (2017-09-26 00:03:18)

Re: Year 2038 problem.

#13 2017-09-26 00:33:33, last edited by soniiiety (2017-09-26 00:34:13)

Re: Year 2038 problem.

#14 2017-09-26 01:01:53

Re: Year 2038 problem.

#15 2017-09-27 20:57:36

Re: Year 2038 problem.

Board footer