Windows 10 Mobile and the Year 2038 Problem

[Cory Nelson]

Chiming in here as a systems developer with a couple decades of experience...

Your CPU's architecture does not dictate the size of numbers used by software. By using literally the same basic arithmetic we learn in school, computers can build a 64-bit number from two 32-bit numbers, just like we can build a larger number from two or more of our 0-9 digits.

The three common modern OSes -- Linux, Mac, and Windows -- have all used 64-bit times internally for a decade or more, even on 32-bit hardware. Now, some poorly made software could potentially be assuming it is 32-bit, and this will be the source of any issues come the year 2038 -- not the OS itself, but the apps running on it.

C has a time_t type (the source of the "2038 problem") that has traditionally been 32-bit, but does not have to be an in fact in virtually every modern compiler it is now 64-bit.

Windows has the SYSTEMTIME and FILETIME types that it uses internally since Windows 2000 which can represent a range of over 30,000 years.

.NET, which is what most Windows Mobile apps are exclusively made with, has the DateTime type which is 64-bit and is limited, artificially, to just under the year 10000.

Modern phone ecosystems are in a uniquely good position because most of the apps made for them have never had a chance to use a 32-bit time -- their platform never exposed one, but instead already had a 64-bit one. The app developer would need to be doing something too clever for their own good to screw it up. Desktop software is where the hurt will be come 2038.

 

[Techno-Freak]

Keeping all the technicalities aside, we'll have more important problems to deal with by the year 2038 than a mobile phone OS, trust me.

 

[PGrey]

Good point Cory, I've used these constructs too, many times, not sure why it slipped my mind, they fact they're using a double value here, on 32...

I bet there are some convoluted 3rd party implementations that will screw this up though, but probably more in the desktop or server Windows, than mobile.

 

[Snowbooks1419]

Chiming in here as a systems developer with a couple decades of experience...

Your CPU's architecture does not dictate the size of numbers used by software. By using literally the same basic arithmetic we learn in school, computers can build a 64-bit number from two 32-bit numbers, just like we can build a larger number from two or more of our 0-9 digits.

The three common modern OSes -- Linux, Mac, and Windows -- have all used 64-bit times internally for a decade or more, even on 32-bit hardware. Now, some poorly made software could potentially be assuming it is 32-bit, and this will be the source of any issues come the year 2038 -- not the OS itself, but the apps running on it.

C has a time_t type (the source of the "2038 problem") that has traditionally been 32-bit, but does not have to be an in fact in virtually every modern compiler it is now 64-bit.

Windows has the SYSTEMTIME and FILETIME types that it uses internally since Windows 2000 which can represent a range of over 30,000 years.

.NET, which is what most Windows Mobile apps are exclusively made with, has the DateTime type which is 64-bit and is limited, artificially, to just under the year 10000.

Modern phone ecosystems are in a uniquely good position because most of the apps made for them have never had a chance to use a 32-bit time -- their platform never exposed one, but instead already had a 64-bit one. The app developer would need to be doing something too clever for their own good to screw it up. Desktop software is where the hurt will be come 2038.

Thank you for the response! So, just to clarify, operating systems and most mobile applications won't be affected by the problem, no matter whether they're 32- or 64-bit? Also, will desktop applications like Microsoft Office continue to work in 2038, even if they're 32-bit? Or is it all 32-bit desktop software that will be affected?

 

[PGrey]

Thank you for the response! So, just to clarify, operating systems and most mobile applications won't be affected by the problem, no matter whether they're 32- or 64-bit? Also, will desktop applications like Microsoft Office continue to work in 2038, even if they're 32-bit? Or is it all 32-bit desktop software that will be affected?

Yep, as Cory was so good to bring up, Win took care of this (in all Win32, C-runtime, and .NET) implementations quite some time ago.
So, as long as app developers didn't develop their own, convoluted versions of this, either directly in code, or in linked libraries or similar, then there will be no issue.
It should be safe to assume that *almost no* desktop or mobile Windows apps (or most OS's given that the runtime is similar in this regard) will be affected. I'm sure there are some random embedded solutions (not necessarily Windows, or probably not). It looks like WinCE even went back and patched this:
https://bugzilla.mozilla.org/show_bug.cgi?id=492450

If you have an app you're concerned about, you could try manually "advancing" your clock to 2039, and see what happens.

I think plenty of others have pointed out though (I said something to this effect earlier too), that this is probably the lesser of many issues that could/would affect things, between now and 2038... ;-]

-pete

 

[Grimwar]

Hmm i am MAD, 22 years? ARE you INSANE

 

[etphoto]

I added this thread to my favorites so in 2037 I can come back here to learn what to do in preparation for 2038.

Sent from my Surface 3

 

[Grimwar]

I added this thread to my favorites so in 2037 I can come back here to learn what to do in preparation for 2038.

Sent from my Surface 3

Error 404

 

[digitaldd]

Time to calculate the 64bit limit for unix time and start the panic, for when 64bit computing ends..

 

[gwinegarden]

Yeah, I remember back in the 60s and 70s, the people writing software new good and well that there would be an issue in the year 2000. However, it was so far away, they all had the attitude that "nobody will be using this in 30+ years.".

You are partially correct. I was writing mainframe programs in the 60's. The real reason we used 6 character dates, back then, was that we couldn't afford not to. Memory, then, was in K (!). We ran an insurance company using a Honeywell 120 with 20K. The next company that I worked for had 24 (wow).

I had a program, in production, that had 12 characters left in memory (not even bytes, as it was an octal machine). Every change that needed making required my determining how much memory it would take and then go looking for it. In 1967, memory cost 10's of thousands of dollars per K and tapes were $50 each. Disks were coming in but had very low capacity. We became very good at saving memory and tape/disk space.

So, yes we knew and did think the programs would not be around in 2000 and I find it difficult to believe that those that I wrote, back then, were, but, later, when resources became cheaper, companies were still reluctant to pay and programmers still kept up their bad habits.

 

[rhapdog]

You are partially correct. I was writing mainframe programs in the 60's. The real reason we used 6 character dates, back then, was that we couldn't afford not to. Memory, then, was in K (!).

Right you are. Sometimes we forget things in our old age. I had to write computer programs on paper and then the assigned person would "input" the program I wrote. Then I would wait for a printout so that I could see it worked as expected, or not. You pretty much had to "run the program" with pencil and paper to make sure everything should work as expected before turning it in, because computer time was so valuable. If you wrote a sloppy program, or a bloated program, you were terminated for it.

I'm glad to be retired and staying home now.

 

[DavidinCT]

As some of you may already know, the "Year 2038 Problem" refers to a predicted event in which many (if not all) 32-bit devices will stop working due to a bug with the UNIX timestamp. However, Windows 10 Mobile is currently 32-bit. If I got a Windows 10 Mobile phone (with a 64-bit processor like the 950 or 950 XL, so that a 32-bit processor wouldn't be an issue), would the fact that Windows 10 Mobile is 32-bit mean that it would stop working in 2038?

OH NO THE WORLD IS ENDING !

Really ? If you still have your 950XL or 950 in 2038, I would be impressed but, I would put a sum of money up that you wont be using it. Most people don't hold on to their phones more than 2-3 years, even the hold outs to refuse to upgrade for 10 years, I don't see this becoming a problem.

Now if you said the issue was in 2020....there might be an issue but, 2038, I think your a little out there even bringing up this subject..... Again I bet 99% of people on this site will NOT be using the same phone they are now in 2038....

 

[gbm97]

I'm a die hard Insider.
I wont be here but a solar powered charger can be hooked up, providing the undertaker doesn't steal it.

 

[rhapdog]

Again I bet 99% of people on this site will NOT be using the same phone they are now in 2038....

LOL.

99% means 1 out of every hundred people would be using the same phone. Out of a million people, that's 10,000 people using the same phone in 22 years.

That would be like me using my first "mobile" phone.


Just like the radio for this phone is no longer compatible with current networks, I would imagine with roll out of 5G or 6G that current phones won't be compatible with newer networks in 2038.

 

[DavidinCT]

Yea for sure. I said 99% because of some of the fanboys who love their phone and would take offence to that statement. I would bet it's over 99.9999999% and there will be one guy/gal who figures out to mod a old device to make it work (retro stuff). Even toi work on a OLD N wi-fi network (think of how wi-fi will change in 22 years)

So it's 2016... in 22 years (2038), does anyone think a phone of today will be compatable with any networks when we are on 12g (or what ever it's called in 22 years) ?

Think of what type of phones we had 10 years ago, how about 15 years ? Yea, not much to really talk about there. In 22 years, everything will be completly different.

The market and tech changes too fast to be using a current device in 22 years from now... If they will even work (on networks, batteries or sources for replacement parts, etc) then...

Maybe by then they will come up with some tech that makes a battery in a phone last LONGER than a day or 2..... sigh....a week or a month would be nice.

 

[PGrey]

The battery thing is a good point, I'm sure tech will have advanced dramatically, and not to mention the zillions of security issues you'd have, using a 950 in 2038, long after its sunset timeframe.
Look at the 2G AT&T sunset going at EOY, some of those phones aren't that old (most are though, realistically), certainly not 22 years. I'm sure we'll be on 7G or LTE-8 or whatever by then, and 75 or 150mbps will seem like snails-pace, more or less like dial-up does now...

Right you are. Sometimes we forget things in our old age. I had to write computer programs on paper and then the assigned person would "input" the program I wrote. Then I would wait for a printout so that I could see it worked as expected, or not. You pretty much had to "run the program" with pencil and paper to make sure everything should work as expected before turning it in, because computer time was so valuable. If you wrote a sloppy program, or a bloated program, you were terminated for it.

I'm glad to be retired and staying home now.

I sort of caught the tail-end of that era, my first CS class we ran stuff on the VAX mostly, and wrote system code on the PDP-11's, for exclusive use.
My first year, we had to batch our jobs, and wait for them to run, and then pick up our print-outs, to debug. The next year, we finally got console redirection, and could view everything on-screen, how cool was that. And then we got Apollo computers to do our 3D modeling classes on, man I spent some long nights working on my splines, fractals, and pages and pages of matrix math ;-]

 

[aaronfranke]

The three common modern OSes -- Linux, Mac, and Windows -- have all used 64-bit times internally for a decade or more, even on 32-bit hardware.

Wrong - 32-bit Linux uses a 32-bit `time_t` type, and this will never change, due to them not wanting to break backwards compatibility with 32-bit Linux userspace programs. Linus Torvalds has a motto: "WE DO NOT BREAK USERSPACE!"