2038 patch?

[jeff.sadowski]

Could it be as simple as
+#define __TIME_T_TYPE __U64_TYPE
-#define __TIME_T_TYPE __SLONGWORD_TYPE

and recompiling the libraries dealing with ctime?
I want to be able to report time past Jan 1, 1970
and convert it to 3 letter Month, Day of Month and 4+ digit year
on 32 bit systems. Do I just need to write my own function up
or is there a easy way to patch and use system libraries.
Why are they phasing out 32 bit machines so soon.

I have some functions written up in bash to deal with this but my method seems kind of kludgey. Icheck each year between to see if it is a leap year. While it is kludgey at least it works.
Follows is what I have in bash I can easily port it to C



# Remove Leading Zeros
#
# Example:
# rlz 04
# 4
rlz(){ echo $1|awk '{print $1 + 0 }';}

# convert Time from Hour:Minute:Seconds AMPM to
# seconds from the beginning of the day
#
# Example 1:
# Time 12:00:00 AM
# 0
# Example 2:
# Time 12:00:00 PM
# 43200
# Example 3:
# Time 11:59:59 PM
# 86399
Time(){
HOUR=`rlz \`echo $1|cut -d: -f1\``
MINUTES=`rlz \`echo $1|cut -d: -f2\``
Seconds=`rlz \`echo $1|cut -d: -f3\``
AMPM=`echo $2|sed 's/[pP][Mm]/PM/'`
if [ "${AMPM}" != "" ];then if [ "${HOUR}" = "12" ];then HOUR=0;fi;fi
if [ "${AMPM}" = "PM" ]; then let HOUR=${HOUR}+12;fi
let Seconds=${HOUR}*60*60+${MINUTES}*60+${Seconds}
echo ${Seconds}
}

# output 1 if the given year is a leapyear
# output 0 if not
#
# Example 1:
# leap_year 2008
# 1
# Example 2:
# leap_year 2010
# 0
leap_year(){
ly=0;let x=$1%400;
if [ "$x" = "0" ];then ly=1 ;else let x=$1%100;
if [ "$x" != "0" ];then let x=$1%4;
if [ "$x" = "0" ];then ly=1;fi;fi;fi
echo ${ly}
}

# day of year
# 1 being January 1
# 365 being December 31 on a non leapyear
# 366 being December 31 on a leapyear
#
# Example 1:
# doy 2010 May 1
# 121 of 365
# Example 2:
# doy 2008 May 1
# 122 of 366
doy()
{
Day=`rlz $3`
ly=`leap_year $1`;
case "$2" in
1|01|Jan) let x=${Day} ;;
2|02|Feb) let x=31+${Day} ;;
3|03|Mar) let x=59+$ly+${Day} ;;
4|04|Apr) let x=90+$ly+${Day} ;;
5|05|May) let x=120+$ly+${Day} ;;
6|06|Jun) let x=151+$ly+${Day} ;;
7|07|Jul) let x=181+$ly+${Day} ;;
8|08|Aug) let x=212+$ly+${Day} ;;
9|09|Sep) let x=243+$ly+${Day} ;;
10|Oct) let x=273+$ly+${Day} ;;
11|Nov) let x=304+$ly+${Day} ;;
12|Dec) let x=334+$ly+${Day} ;;
esac
let y=365+$ly
echo $x of $y
}

# days of years in between
# Given two years it calculates the days of the years
# in between those two years
# Obviously if the years are the same there are zero days in between
# Also if the years are right next to each other there are zero days
# in between the two years. If the years have one year in between them
# there will be 365 plus leapyear status days between them. If there
# are 2 years between them there will be 730 or 731 days between them
#
# Example 1:
# days_of_yib 2007 2009
# 366
# Example 2:
# days_of_yib 2006 2009
# 731
days_of_yib(){
if [ $1 = $2 ];then echo 0
elif [ $1 -gt $2 ];then
let x=$1-$2-1
if [ ${x} -gt 0 ];then
let minus_one=$1-1
let y=365+`leap_year ${minus_one}`+`days_of_yib ${minus_one} $2`
echo $y
else echo 0
fi
else days_of_yib $2 $1
fi
}

# Given 2 dates it calculates the days in between them
#
# Example 1:
# days_apart 2009 May 05 2010 May 05
# -365
# Example 2:
# days_apart 2010 May 05 2009 May 06
# 364
days_apart()
{
one=`doy $1 $2 $3`
two=`doy $4 $5 $6`
if [ $1 = $4 ];then
let x=`echo $one $two| awk '{print $1-$4}'`
else
doyib=`days_of_yib $1 $4`
if [ $1 -lt $4 ];then
let x=`echo $one $two ${doyib}| awk '{print -($7+$4+$3-$1)}'`
else
let x=`echo $two $one ${doyib}| awk '{print $7+$4+$3-$1}'`
fi;fi
echo ${x}
}

# Given Two Sets of Date and Time return the number of seconds between them.
#
# Example 1:
# seconds_apart 2010 May 1 12:00:00 AM 2010 Apr 30 11:59:59 PM
# 1
# Example 2:
# seconds_apart 2010 Apr 30 11:59:59 PM 2010 May 1 12:00:00 AM
# -1
# seconds_apart 2038 Jan 19 03:14:07 AM 1970 Jan 1 12:00:00 AM
# 2147483647
seconds_apart(){
days=`days_apart $1 $2 $3 $6 $7 $8`
let x=`Time $4 $5`-`Time $9 ${10}`+$days*86400
echo $x
}

# Given a Date and Time it tells how many seconds ago that time was
# negative if that time hasn't occured yet
seconds_ago(){ seconds_apart `date "+%Y %m %d %I:%M:%S %p"` $1 $2 $3 $4 $5;}

seconds_from_epoch(){ seconds_apart $1 $2 $3 $4 $5 1970 1 1 12:00:00 AM; }



I just need a ctime function that I can easily create.

[-humanaut-]

2038 was fixed with 64bit integers I doubt there will be any such patch for 32bit systems considering Enterprising environments have had 64bit systems since 1995 with Solaris. (or the release of the Sun Ultra 5/10) I wouldn't hold my breath for a 32bit patch that is taken serious. Considering the Direction of personal Computers has been 64bit for sometime now.

[jeff.sadowski]

2038 was fixed with 64bit integers I doubt there will be any such patch for 32bit systems considering Enterprising environments have had 64bit systems since 1995 with Solaris. (or the release of the Sun Ultra 5/10) I wouldn't hold my breath for a 32bit patch that is taken serious. Considering the Direction of personal Computers has been 64bit for sometime now.

Not quite most embedded systems for Enterprise Environments are still 32 bit. And there really is no need for 64bit chips for simple tasks. In fact I can see this issue popping up mostly for inexpensive chips well beyond 2038. 32 bit architectures although not as useful for high end computing are perfectly suitable for simple tasks. In fact a 64 bit chip in some circumstances would not be as efficient. What about embedded ARM chips in
cell phones, watches and the like. I know most will be replaced by then but still I have not seen a 64 bit chip on embedded systems like Gumstix or the like. I don't plan to either. The only thing that is effected is the time and it can easily work just fine with some simple patches. I can write the patches if I just knew where to look. I'd rather fix it than just ignore it like most people seem to.

[wmcbrine]

People will start to care about this around 2036 or so.

[trent.josephsen]

Not quite most embedded systems for Enterprise Environments are still 32 bit. And there really is no need for 64bit chips for simple tasks. In fact I can see this issue popping up mostly for inexpensive chips well beyond 2038. 32 bit architectures although not as useful for high end computing are perfectly suitable for simple tasks. In fact a 64 bit chip in some circumstances would not be as efficient. What about embedded ARM chips in
cell phones, watches and the like. I know most will be replaced by then but still I have not seen a 64 bit chip on embedded systems like Gumstix or the like. I don't plan to either. The only thing that is effected is the time and it can easily work just fine with some simple patches. I can write the patches if I just knew where to look. I'd rather fix it than just ignore it like most people seem to.

Most embedded systems don't run Unix, and can pick any arbitrary time as an epoch. For my calculator, for instance, the epoch is January 1, 1997. With a little bit of care, it's a non-issue.

[wmcbrine]

People will start to care about this around 2036 or so.I should add that there's actually a separate Y2036 problem, for things that use an unsigned 32-bit second count from 1900, like NTP.

[nikstard]

If people are still running *nix in 2038, this issue is the least of their concerns.

[jeff.sadowski]

If people are still running *nix in 2038, this issue is the least of their concerns.

This is not strictly a *nix problem. It is any system that increments a counter every second using that counter as a date field based off of jan 1 1970 on 32 bit systems. Windows on 32 bit platforms have the same issue. Don't forget NT was POSIX compliant. Mac OS X is based on FreeBSD and those iphones I know are 32 bit processors. I know, no iphone will last to 2038 but embedded systems I guarantee will. In fact there is no operating system that will not have to deal with this on 32 bit architectures.

A good portion of embedded devices are using *nix.
Examples of where this might be an issue. Remote access tools. HP and Dell have onboard Remote Access modules on there computers that allow you to access the remote screen via a web interface(In HP it is called ILO). I am fairly certain both of them use linux as their Remote access OS. HTTPS may have issues with clocks going that far out of sync. The systems themselfs will be fine given that they are 64 bit systems. There is no need for the remote access boards to be 64 bit processors.

As for picking another date for epoch that is not a bad idea. But given that most calculations use jan 1 1970 as epoch it would be easier to just start using two integers as a 64 bit integer for the date field.

[-humanaut-]

In 28 years if embedded systems (the rare ones that use nix systems) well, I'd bit shocked if there not atleast up to 64bit computing at that point. considering 64bit systems have literally been around since I was a child( 1995ish) I'd imagine this won't be a problem. In 28 years Apple could be extinct and there phones render useless antiques. 28 Years. 2038 Will impact the world much less then Y2K did.

[wmcbrine]

If people are still running *nix in 2038, this issue is the least of their concerns.In addition to what Jeff said... *nix has lasted for almost four decades already, and has kept pace with the times. What makes you think it won't last another three? And what's going to replace it? The opposite seems to be a lot more common, so far: *nix displacing other systems.

[jeff.sadowski]

In 28 years if embedded systems (the rare ones that use nix systems) well, I'd bit shocked if there not atleast up to 64bit computing at that point. considering 64bit systems have literally been around since I was a child( 1995ish) I'd imagine this won't be a problem. In 28 years Apple could be extinct and there phones render useless antiques. 28 Years. 2038 Will impact the world much less then Y2K did.

Don't take this the wrong way it is just an example. Do you have incandescent light bulbs in your house somewhere?, I'm going to guess yes, at least one. Maybe because they are cheap and work better in some circumstances or because you don't like CFL's (afraid of mercury poisoning or need a heat source). How old is the technology in incandescent light bulbs? They are pretty old. Why are they cheap? because they can be manufactured easier than others and have been mass produced. Same goes for at least ARM 32 bit chips. They are small, use less energy, and are stamped out by the thousands. Maybe in the future 64 bit chips will come down in size and price to match these small footprint chips. But even still the 32 bit chips could get even smaller. (since their circuitry is smaller) a fact of reality.

*nix will be around still for a number of reasons. You will still see it.
I just want the *nix's still around to work the same on 32 bit processors (that will still be around) and 64 bit or even 128 bit processors. Who knows we could have quantum chips by then. Then again its not really that far off. Regardless some of the well thought out algorithms will port to it. There will still be a use for linux on 32 bit processors. I'd like my date functions to work without my own crude replacement functions to work around operating system limitations. I'm not a bad programmer but its nice if I don't have all these small quirks I have to program around. Admittedly even 64 bit has its limit and I'm just pushing out the problem but its a factor of 2^31 out at least and that is a good fail date.

[-humanaut-]

Don't take this the wrong way it is just an example. Do you have incandescent light bulbs in your house somewhere?, I'm going to guess yes, at least one. Maybe because they are cheap and work better in some circumstances or because you don't like CFL's (afraid of mercury poisoning or need a heat source). How old is the technology in incandescent light bulbs? They are pretty old. Why are they cheap? because they can be manufactured easier than others and have been mass produced. Same goes for at least ARM 32 bit chips. They are small, use less energy, and are stamped out by the thousands. Maybe in the future 64 bit chips will come down in size and price to match these small footprint chips. But even still the 32 bit chips could get even smaller. (since their circuitry is smaller) a fact of reality.

*nix will be around still for a number of reasons. You will still see it.
I just want the *nix's still around to work the same on 32 bit processors (that will still be around) and 64 bit or even 128 bit processors. Who knows we could have quantum chips by then. Then again its not really that far off. Regardless some of the well thought out algorithms will port to it. There will still be a use for linux on 32 bit processors. I'd like my date functions to work without my own crude replacement functions to work around operating system limitations. I'm not a bad programmer but its nice if I don't have all these small quirks I have to program around. Admittedly even 64 bit has its limit and I'm just pushing out the problem but its a factor of 2^31 out at least and that is a good fail date.

Honestly, the very last incandescent light bulb I used was last year. (though I DO NOT support them all being made in China the new ones the name has slipped my mind at the moment but thats politics) Here's the thing, I don't want this to turn into a flame war over 32 & 64bit I agree that there will be some nix systems around in 2038 and it will need to be addressed then, however I also believe based on the movement of the personal computer which has focused on 64bit artictures for sometime now that 2038 truly won't be a problem 64bit was the future 5 years ago and isn't going to slow down. Honestly if you can write a patch that properly fixes the 32bit error that nix developers implemented (though this means nothing) I'd endorse it Honestly don't GPL it and make yourself some money I strongly believe you could if for nothing more then people who fear it (DON'T TAKE THAT THE WRONG WAY) I respect what your trying to accomplish I just don't believe it's a problem anymore considering even Netbooks are close to making the 64bit Leap with the Dual-Core Atom Processors from Intel. But honestly If I could write a program to super-cede the 32bit time algorithm problem I would do it. But I would release it under a lucrative license where Corporations had to pay me and individual would be free to use it at will with no cost. Sorry if it seemed as though I was flaming you I support what your doing but I just believe 64bit machines have cured the issue before it was an issue.

[lostinxlation]

In 28 years if embedded systems (the rare ones that use nix systems) well, I'd bit shocked if there not atleast up to 64bit computing at that point. considering 64bit systems have literally been around since I was a child( 1995ish) I'd imagine this won't be a problem. .
If 64bit is required for embedded systems, it would have already happened, however, I don't even see the slightest sign that embedded market is going to pursue the 64bit path. it's just simply 64bit is not required.
For embedded processor, the cost is very important and making it 64bit will definitely add some more cost. Furthermore, 64bit datapaths cause more power consumption which the system companies want to avoid. The cost and power budget for embedded system is quite tight and unless 64bit is an absolute requirement to run the application, they would stick to 32bit.
Most probably, 32bit systems will be still around in 28 years.

[v8YKxgHe]

removed

[jeff.sadowski]

Do you currently support the architecture of 28 year old CPUs/hardware in your program? When 2038 comes, you're basically saying you're wanting to support 56 year old hardware with your software.

Look realistically: The probability that CPU architecture we have around now, at this current date - which includes 32bit, to be used in 2038 is incredibly unlikely. Plus the fact you're assuming your program is still going to be used by people in 28 years.

Focus on getting your program working now, to the best it can instead of looking around for problems to fix that don't need to be fixed.

From time to time I do calculations involving dates beyond 2038. time, date, position calculations for things like when and where you can expect to find a comet or such. (class work) There is the 32 bit bug on half the computers I work on. I will write my own ctime and such to get around this. But it is silly that I have to write such a patch just for 32 bit systems. I'm not going to replace 20+ systems in the next 2 to 3 years. Most the systems run a pretty up to date ubuntu. That is why I really want the bug fixed and want it fixed in ubuntu. However I dabble with gumstix computers to do home automation, autonomous vehicles, some of which I expect to work past 28 years(at least the programming aspect). I have more control over embedded systems and can mod the OS to work well beyond that. It would be nice if it was adopted beyond the embedded world.

As for them ever going to 64 bit embedded I highly doubt it. As I mentioned 32 bit will always be smaller (one quarter the size) and less power hungry given the nature of the beast. Sure it won't be as fast nor as capable but as I mentioned it has its place. 64 bit chips have so many more pins (4 times as many) trying to make access to them and use it is nearly impossible (as is 32 bit chips are beyond my soldering skills) to do with embedded systems. As is the 32 bit chips are over powered for most tasks. An arduino might suit better for smaller tasks, but you can't run linux on an arduino and make it run standard script that you can do with a gumstix. I can even ssh to my gumstixs through out the house and send them commands to turn something on or off or adjust. Even web to them to send ir commands to other devices. Over the next 28 years I see linux on 32 bit chips working its ways into many aspects of smart homes and appliances. As this happens the 32 bit bug begins to worry me more and more.

As for program usage in the future. I expect all usefull programs to still be here. sed, awk, head, tail, echo, you know the base linux programs. I expect perl and bash to still be around. If written properly and depending on how useful a script I write is and how well documented it is. Yes I do expect some of my scripts to be around beyond 2038.