2038 bug (BSD comparison)
M.K.
date -u -r 2147483648 => Fri Dec 13 20:45:52 UTC 1901 (problem exists)
OpenBSD 3.9/amd64:
date -u -r 2147483648 => Fri Dec 13 20:45:52 GMT 1901 (problem exists)
FreeBSD 6.1/amd64:
date -u -r 2147483648 => Tue Jan 19 03:14:08 UTC 2038 (no problem)
NetBSD 3.0.1/i386:
date -u -r 2147483648 => Tue Jan 19 03:14:07 UTC 2038 (clock freezes at
2147483647)
OpenBSD 3.9/i386:
date -u -r 2147483648 => Tue Jan 19 03:14:07 GMT 2038 (clock freezes at
2147483647)
FreeBSD 6.1/i386:
date -u -r 2147483648 => Fri Dec 13 20:45:52 UTC 1901 (problem exists)
P.S. - I hope you all appreciate the time it took to do this.
jpd
On 2006-10-14, M.K. <mk...@ozemail.com.au> wrote:
> P.S. - I hope you all appreciate the time it took to do this.
Possibly moreso if you hadn't multiposted this. IFF you're posting in
multiple groups, crosspost it instead.
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.
Kris Kennaway
FYI, 64-bit versions of FreeBSD (e.g. amd64, sparc64) use 64-bit
time_t so this isn't an issue there.
Kris
Martin Ebnoether
Hoi.
>> P.S. - I hope you all appreciate the time it took to do this.
Nice idea although I think this issue will be solved in the next 30
years or so. =:O)
> FYI, 64-bit versions of FreeBSD (e.g. amd64, sparc64) use 64-bit
> time_t so this isn't an issue there.
Of course it's posted to a BSD newsgroup, but it would have been
interesting to see what happens on Linux as well.
I might give it a try if I find the time. =:-)
CU, Venty
"james <at> hal-pc.org"
> FYI, 64-bit versions of FreeBSD (e.g. amd64, sparc64) use 64-bit
> time_t so this isn't an issue there.
# date -u -r 2147483648
Fri Dec 13 20:45:52 UTC 1901
Digital AlphaPC 164LX
5.5-STABLE
I take it that doesn't apply to Alpha?
--
- - james <at> hal-pc.org - -
Polish-Dutch-Scottish-Irish-Cherokee-German-Coonass-American and proud
of it!
"Political correctness" will kill us all.
- - - - - - - - - - - - - - -
Kris Kennaway
> Kris Kennaway wrote:
>> FYI, 64-bit versions of FreeBSD (e.g. amd64, sparc64) use 64-bit
>> time_t so this isn't an issue there.
>
> # date -u -r 2147483648
> Fri Dec 13 20:45:52 UTC 1901
>
> Digital AlphaPC 164LX
> 5.5-STABLE
>
> I take it that doesn't apply to Alpha?
Yep. I should have said "supported 64-bit versions of FreeBSD" since
alpha support was terminated a while back after the branch became
unmaintained for a few years.
Kris
Taku
Martin Ebnoether <martin.e...@yahoo.de> wrote:
> Nice idea although I think this issue will be solved in the next 30
> years or so. =:O)
The bank cashing system in Japan had some accidents in January of 2004
by 2038 year problem.
Jan. 11,2004 is the half and a day of the days between 1970
and Jan. 19,2038.
--
Taku mailto:t...@vfemail.net
powered by AMD K6-2-500 on ASUS P5A
Moe Trin
article <2006101819505...@vfemail.net>, Taku wrote:
>Martin Ebnoether <martin.e...@yahoo.de> wrote:
>
>> Nice idea although I think this issue will be solved in the next 30
>> years or so. =:O)
>
>The bank cashing system in Japan had some accidents in January of 2004
>by 2038 year problem.
>Jan. 11,2004 is the half and a day of the days between 1970
>and Jan. 19,2038.
OK - what magic mathematics were they using? Jan. 19, 2038, or more
precisely January 19 03:14:07 UTC 2038 is a problem on 32 bit systems
that measure time in seconds from January 01 00:00:00 UTC 1970 as a
signed integer - as that will be 0x7FFFFFFF seconds. January 11 2004
in Japan would be close to 0x3FFFFFFF seconds (January 10 13:37:03 UTC
2004, or January 10 22:37:03 JST 2004). Are the banks using _31_ bit
systems, or is this a handy excuse that the banks used? "The computer
screwed up, not us!!!"
Are you sure this isn't a separate screwup related to Heisei 16 starting
around that date? I know we made it up to Showa 64, so is there a power
of two function involved? ;-)
Old guy
Taku
ibup...@painkiller.example.tld (Moe Trin) wrote:
> OK - what magic mathematics were they using? Jan. 19, 2038, or more
> precisely January 19 03:14:07 UTC 2038 is a problem on 32 bit systems
> that measure time in seconds from January 01 00:00:00 UTC 1970 as a
> signed integer - as that will be 0x7FFFFFFF seconds. January 11 2004
> in Japan would be close to 0x3FFFFFFF seconds (January 10 13:37:03 UTC
> 2004, or January 10 22:37:03 JST 2004). Are the banks using _31_ bit
> systems, or is this a handy excuse that the banks used? "The computer
> screwed up, not us!!!"
>
> Are you sure this isn't a separate screwup related to Heisei 16 starting
> around that date? I know we made it up to Showa 64, so is there a power
> of two function involved? ;-)
I don't know the detail of that system, and only introduced the report
in the web news in Japanese on 2038 year problem.
That system adopted by 23 banks is worked on IBM software.
Moe Trin
article <2006101921073...@vfemail.net>, Taku wrote:
>ibup...@painkiller.example.tld (Moe Trin) wrote:
>> 0x3FFFFFFF seconds (January 10 13:37:03 UTC 2004, or January 10 2:37:03
>> JST 2004). Are the banks using _31_ bit systems, or is this a handy
>> excuse that the banks used? "The computer screwed up, not us!!!"
>I don't know the detail of that system, and only introduced the report
>in the web news in Japanese on 2038 year problem.
It couldn't be the classic 32 bit time_t problem. Looking at the ACM Risks
Digest (news://comp.risks), there are only two references to Japanese
banks and computers. The first (actually two) are in Risks Vol 22 Issue
3 relating to the merger fiasco in April 2002, and the second relates to
a lost data tape by the Japanese branch of Citibank (but the incident
occurred in Singapore in February 2004) - see Risks Vol 23 Issue 90.
This sounds more like a "blame the computer" exercise than an actual
computer or O/S failure.
Old guy
Taku
OK.
The part of that report is translated by my poor English hereunder.
The software has a function to add somthing to the result multiplied
the time by 2.
That results is over Jan.19,2038 at the morning of Jan.11,2004,
so that the system had an accident.
Kindly browse the following URL, if you can understand Japanese.
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20040202/139212/
Thanks.
Moe Trin
article <2006102020300...@vfemail.net>, Taku wrote:
>ibup...@painkiller.example.tld (Moe Trin) wrote:
>> It couldn't be the classic 32 bit time_t problem. Looking at the ACM Risks
>> Digest (news://comp.risks), there are only two references to Japanese
>> banks and computers. The first (actually two) are in Risks Vol 22 Issue
>> 3 relating to the merger fiasco in April 2002, and the second relates to
>> a lost data tape by the Japanese branch of Citibank (but the incident
>> occurred in Singapore in February 2004) - see Risks Vol 23 Issue 90.
>The part of that report is translated by my poor English hereunder.
Your English is much better than my Japanese.
>The software has a function to add somthing to the result multiplied
>the time by 2.
>That results is over Jan.19,2038 at the morning of Jan.11,2004,
>so that the system had an accident.
>
>Kindly browse the following URL, if you can understand Japanese.
My Japanese is limited to a few hundred words, and I can only read in
Romanji. However I spent some time looking on google (the search terms
I used at google were "Japanese 2038 bank problem", but I also looked at
"Japanese bank problem January 2004"), and the only thing I find in
English seems to be multiple sites repeating the same very limited
information from the "Matatabi Report" (Japan Tech News Digest).
In January, 11th when the UNIX clock reached half its useful positive
range between 1970 and 2038, the ATMs of more than 20 banks in Japan
broke down because software in those systems had a process in which
time values were multiplied by two.
however there is no further details. The article also mentions "The Year
2038 Bug Affects KDDI Phone Bill":
KDDI acknowledged that the company billed 45,866 subscribers incorrectly
due to the year 2038 bug in UNIX OS. As the billing system had
problems in handling of time values, some customers were overcharged
by getting the weekday rates during weekends and national holidays,
while the others were undercharged by getting the weekend discounts in
business days. The problems occurred between January 10th and February
25th. Billing adjustments for those affected will be made after March.
In both cases, it's an application that screwed up, not the O/S itself.
However as noted above, I still have been unable to find any mention of
these incidents in the ACM reports. The KDDI problem seems to suggest
that time_t being doubled somehow gives a clue as to day of week, and I
have _no_ idea how they figured that.
Old guy
Taku
ibup...@painkiller.example.tld (Moe Trin) wrote:
> My Japanese is limited to a few hundred words, and I can only read in
Thanks.
> Romanji. However I spent some time looking on google (the search terms
> I used at google were "Japanese 2038 bank problem", but I also looked at
> "Japanese bank problem January 2004"), and the only thing I find in
> English seems to be multiple sites repeating the same very limited
> information from the "Matatabi Report" (Japan Tech News Digest).
>
> In January, 11th when the UNIX clock reached half its useful positive
> range between 1970 and 2038, the ATMs of more than 20 banks in Japan
> broke down because software in those systems had a process in which
> time values were multiplied by two.
>
That is right.
That report introduced the incident happened to ATM.
(I appologized that I did not use the word of ATM, as I understood
ATM may be named other words in the other countries.)
> however there is no further details. The article also mentions "The Year
> 2038 Bug Affects KDDI Phone Bill":
>
> KDDI acknowledged that the company billed 45,866 subscribers incorrectly
> due to the year 2038 bug in UNIX OS. As the billing system had
> problems in handling of time values, some customers were overcharged
> by getting the weekday rates during weekends and national holidays,
> while the others were undercharged by getting the weekend discounts in
> business days. The problems occurred between January 10th and February
> 25th. Billing adjustments for those affected will be made after March.
>
> In both cases, it's an application that screwed up, not the O/S itself.
> However as noted above, I still have been unable to find any mention of
> these incidents in the ACM reports. The KDDI problem seems to suggest
> that time_t being doubled somehow gives a clue as to day of week, and I
> have _no_ idea how they figured that.
--