Hello All,

The company I work for has asked me to research the possibility of an ASNI C 
runtime library overflow bug for 2010 in the date routines, specifically as 
to whether it is a real problem or whether it was fabricated at Y2K time as 
a means of further scare-mongering. The reason I say scare-mongering is 
because I can find no absolute description of a problem relating to this on 
the internet (my biggest source of information). I can find many documents 
that state it exists but no details and, funnily enough, they all seem to be 
cloned from an original source - the wording is normally exact.

If a problem does exist in the date routines of the ASNI libraries, does 
anyone have any examples or theoretical papers on what may (or may not) be 
the cause?

Personally, I feel that any such overflow might occur in date manipulation 
routines (adding, subtracting, etc) particularly in smaller word length 
processor environments (16-bit for example). I cannot prove this, nor do I 
wish to. I submit that as a pre-cursor to discussion only.

I can assure you that my intention is purely research and by no means is 
this query meant to provoke any kind of heated response or business-wide 
'panic'. I simply need expert help.

Any assistance you can give would be greatly appreciated.

Regards,

Adrian Birkett 

"Ade" <adrian.birkett@blueyonder.co.uk> writes:
> The company I work for has asked me to research the possibility of an ASNI C 
> runtime library overflow bug for 2010 in the date routines, specifically as 
> to whether it is a real problem or whether it was fabricated at Y2K time as 
> a means of further scare-mongering. The reason I say scare-mongering is 
> because I can find no absolute description of a problem relating to this on 
> the internet (my biggest source of information). I can find many documents 
> that state it exists but no details and, funnily enough, they all seem to be 
> cloned from an original source - the wording is normally exact.
>
> If a problem does exist in the date routines of the ASNI libraries, does 
> anyone have any examples or theoretical papers on what may (or may not) be 
> the cause?
>
> Personally, I feel that any such overflow might occur in date manipulation 
> routines (adding, subtracting, etc) particularly in smaller word length 
> processor environments (16-bit for example). I cannot prove this, nor do I 
> wish to. I submit that as a pre-cursor to discussion only.
>
> I can assure you that my intention is purely research and by no means is 
> this query meant to provoke any kind of heated response or business-wide 
> 'panic'. I simply need expert help.

(You mean "ANSI", not "ASNI" -- and you probably *should* mean ISO,
since that's the organization that owns and publishes the C standard.)

I know of no such problems related to the year 2010.  The C standard's
definition of the time_t function is so vague (it merely needs to be
an arithmetic type capable of representing times) that you can't infer
anything about time_t overflow from the standard itself.  Some of the
manipulation functions might have problems; for example asctime() or
ctime() would overflow its static buffer in the year 10000.

The most common representation for time_t is an integer representing
the number of seconds since 1970-01-01 00:00:00 UTC.  With a 32-bit
signed representation, that will overflow at Tue 2038-01-19 03:14:07
UTC (the infamous Y2038 problem).  IMHO that leaves us more than
enough time to transition to 64-bit time_t, unless you're dealing with
timestamps in the future.

There have been a number of other times that have caused, or might
cause, problems for some systems.  For example, I saw a problem on one
system when the current time_t value reached one billion (Sun
2001-09-09 01:46:40 UTC).  Other problems have occurred for leap
years, such as for code that doesn't anticipate a year having 366
days.  But these problems are system-specific, not related to the ISO
C language or library.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On June 11, 2009 16:37, in comp.lang.c, Ade
(adrian.birkett@blueyonder.co.uk) wrote:

> Hello All,
> 
> The company I work for has asked me to research the possibility of an ASNI
> C runtime library overflow bug for 2010 in the date routines,


I do not know of /any/ "overflow bug" in the ANSI/ISO C suite that will
occur in 2010.

Perhaps you are thinking of the well-known exposure on certain systems (of
Unix-like derivation) where time_t is defined as a 32-bit signed integer,
and the results of the time() call are expressed as a value of seconds
since midnight, Jan 1, 1970. This representation will overflow at 03:14:07
UTC on January 19, 2038. 

However, the C standard does /not/ dictate that time_t be defined as a
signed 32-bit integer, or that the time() call return a value of seconds
since midnight Jan 1, 1970.

-- 
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/   | GPG public key available by request
----------      Slackware - Because I know what I'm doing.          ------

Ade <adrian.birkett@blueyonder.co.uk> wrote:
>The company I work for has asked me to research the possibility of an ASNI C 
>runtime library overflow bug for 2010 in the date routines

You should provide the links you already have.

I've never heard of this, but apparently there's some problem with
Newton OS which I guess has a 30-bit time_t with some weird offset, or
something--I didn't really read it:

http://40hz.org/Pages/Newton%20Year%202010%20Problem

The Spec pretty much allows any range and precision of times by an
implementation, so the Newton's not out of line; there's nothing in the
spec that prevents a system from having an atomic clock good until the
year 10 billion, or, for that matter, a clock that fails in 2010.

C99 7.23.1p4:
# The range and precision of times representable in clock_t and time_t
# are implementation-defined.

C99 7.23.2.4p3:
# The time function returns the implementation's best approximation to
# the current calendar time.

I'm pretty sure my Unix boxes (and other people's Windows boxes :) )
will keep humming past 2010 without a date problem.

-Beej

On 11 Jun 2009 at 20:51, Keith Thompson wrote:
> I know of no such problems related to the year 2010.

Right. 2038 is the key date, though by then all the world will be
64-bit and there won't be any problem.

Some dry humor from Wikipedia:
"Using a (signed) 64-bit value introduces a new wraparound date in
approximately 292 billion years on Sunday, December 4, 292,277,026,596."

> The most common representation for time_t is an integer representing
> the number of seconds since 1970-01-01 00:00:00 UTC.

Is it really the most common? I'm a *nix buff as much as the next man,
but you'd have to admit that MicroSoft has a pretty large share of the
desktop market.

Antoninus Twink wrote:

> Some dry humor from Wikipedia:
> "Using a (signed) 64-bit value introduces a new wraparound date in
> approximately 292 billion years on Sunday, December 4, 292,277,026,596."
> 


Went to the mart to buy some cigarettes, and
when the maid smiled behind the counter I thought
of the time when she will be completely gone.

I thought that a time will come when the cigarette store
will be gone, together with its enclosing mart, yes.

A time will come when the continent will be gone where
we build our cigarette stores, a time when the sun that
gives us light, and even the galaxy will be gone.

Together with all species in the galaxy
that suicide themselves with smoke.

Gone up in smoke. All of them. Yes, a time will come when
December 4th 297 277 026 596 arrives.

What a surprise when preparing for Christmas. I thought,
yes I thought I should get some cigarettes from the store.

Was a long time coming 297 277 026 596 but eventually...

Eventually December 4th arrived.

Keith Thompson wrote:

> The most common representation for time_t is an integer representing
> the number of seconds since 1970-01-01 00:00:00 UTC.  With a 32-bit
> signed representation, that will overflow at Tue 2038-01-19 03:14:07
> UTC (the infamous Y2038 problem).  IMHO that leaves us more than
> enough time to transition to 64-bit time_t, unless you're dealing with
> timestamps in the future.

Yup, there is enough time, but not every computer is high-end server or 
PC,  and I wouldn't be too surprised if the embedded world isn't 64-bit 
by 2038 - LIFETIME_OF_UNIT.

....and for the rest, how many have used e.g. the gcc option -m32,  to be 
done with a 64-bit port in a moment?

None?! :)

My bet would that there are now a lot of 32-bit programs running on 
64-bit systems, and for those having done the porting, there is still a 
chance that the programmer unintentionally do a 32-bit cast during time 
computations.

-- 
Tor <echo bwzcab@wvtqvm.vw | tr i-za-h a-z>

On Jun 11, 4:24=A0pm, Antoninus Twink <nos...@nospam.invalid> wrote:
> On 11 Jun 2009 at 20:51, Keith Thompson wrote:
>
> > I know of no such problems related to the year 2010.
>
> Right. 2038 is the key date, though by then all the world will be
> 64-bit and there won't be any problem.
>
> Some dry humor from Wikipedia:
> "Using a (signed) 64-bit value introduces a new wraparound date in
> approximately 292 billion years on Sunday, December 4, 292,277,026,596."
>
> > The most common representation for time_t is an integer representing
> > the number of seconds since 1970-01-01 00:00:00 UTC.
>
> Is it really the most common? I'm a *nix buff as much as the next man,
> but you'd have to admit that MicroSoft has a pretty large share of the
> desktop market.


32 bit time_t's on Windows are typically the same and the *nix
versions.  Windows itself tend not to use that as a time base
internally, but MS's CRT does.

Thanks all for your responses.

Err... yes, I did mean "ANSI" and can't think why I spelt it incorrectly 
throughout - sorry.

Some links that mention it...

http://www.ugu.com/sui/ugu/showclassic?I=y2k.dates&F=0111111111&G=Y

http://www.ismosys.com/downloads/general/Dates%20potentially%20causing%20computer%20problems.pdf

I wasn't aware of the Newton problem but this does seem to be the likely 
candidate

http://40hz.org/Pages/Newton%20Year%202010%20Problem

Thanks again. I hope there are no smelling pistakes in this posting :-)


Ade 

"Ade" <adrian.birkett@blueyonder.co.uk> writes:
> Thanks all for your responses.
>
> Err... yes, I did mean "ANSI" and can't think why I spelt it incorrectly 
> throughout - sorry.
>
> Some links that mention it...
>
> http://www.ugu.com/sui/ugu/showclassic?I=y2k.dates&F=0111111111&G=Y

This mentions:

    January 1, 2010 - Overflow ANSI C Library (Note: This event is
    alleged to be a valid Y2K problem date. I do not have any
    additional information on this claim)

As far as I know, this is nonsense.

> http://www.ismosys.com/downloads/general/Dates%20potentially%20causing%20computer%20problems.pdf

This also says:

    2010/01/01: Overflow for ANSI C library.

And:

    2034/09/30: Overflow for UNIX time function.

I can't figure out the significance of that date, and I don't believe
there is any.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

>The company I work for has asked me to research the possibility of an ASNI C 
>runtime library overflow bug for 2010 in the date routines, specifically as 
>to whether it is a real problem or whether it was fabricated at Y2K time as 
>a means of further scare-mongering. 

ANSI C specifies very little about the date routines.  In particular:

- It does NOT specify that a time_t is 32 bits.
- It does NOT specify that a time_t represents a count of the number
  of <insert some time unit here> since <fixed time>.  It especially
  doesn't specify that a time_t represents a number of seconds.
- It does NOT specify that if you subtract two time_t's, you get anything
  meaningful.  Even the sign of the result is useless.  Try, for example, 
  subtracting 12311999 (December 31, 1999) from 01012000 (January 1, 2000).  
  You get -11299999, which doesn't mean much.

There is no problem with "ANSI C date routines" in common; you have
to specify a particular implementation.  "Cars will run out of gas
by June 17, 2009".  Well, mine probably will if I don't fill it up
first.

A time_t could, for example, increment by one every time there's
an earthquake in California.  For that, I guess you'd need a 128-bit
integer.  A time_t could, for example, increment by one every time
there's an earthquake in Texas.  With 5 in a week recently in or
near one city, that might overflow an 8-bit integer faster than you
think.

>The reason I say scare-mongering is 
>because I can find no absolute description of a problem relating to this on 
>the internet (my biggest source of information). I can find many documents 
>that state it exists but no details and, funnily enough, they all seem to be 

Post the documents, or at least pointers to them.  I can do Google searches
too, but I want to see what *YOU* see.

>cloned from an original source - the wording is normally exact.

So let's see the exact wording.

>If a problem does exist in the date routines of the ASNI libraries, does 
>anyone have any examples or theoretical papers on what may (or may not) be 
>the cause?

The common implementation of time_t, as a 32-bit number of seconds
since January 1, 1970 00:00 GMT, will overflow into the sign bit
on Jan 19, 2038.  The obvious fix for this is to extend it to 64
bits.  Many systems have already done this.

The asctime() and ctime() routines have a Y10K problem, since the
format for a printable date is specified as having 4 digits.  Someone
might misinterpret Y10K as meaning 2010 instead of 10000.

The struct tm element tm_year is subject to overflow (of either 16-bit
or 32-bit integers) if you extend time_t to 64 bits as a number of seconds
since January 1, 1970 0:00:00 GMT.  This first happens for the year
32768+1900 on a machine with 16-bit ints, unless time_t runs out first.

There *is* a real 2010 time bug in NewtonOS on January 5, 2010, in
some functions in NewtonScript.  This clock uses a number of seconds
since January 1, 1993, and uses a 30-bit integer.  As far as I know,
there is no implementation of C built on NewtonScript.  There is a
(or maybe several) C++ implementation on NewtonOS; it uses (unsigned
32-bit) dates from 1904-2040 without problems.  Does your company 
depend on Apple Newtons to conduct its business?

The GPS week number (0-1023) overflowed on August 21, 1999.  The
next overflow is due about 19.6 years from then.  That's not close
to 2010.

There is a real problem representing the maturity date of a 28-year
mortgage issued in 2010.  As far as I know, nobody issues 28-year
mortgages.  30-year mortgages used to be common, and that overflow
has already happened.  Banks used to have money, also.  Besides,
banks want to represent the day, not the time, as time_t does funny
things with time zones that don't jive with the way banks do business.

Some economists are projecting the US national debt will overflow
an integer in 2010.  That's a 64-bit, 128-bit, 256-bit, or 512-bit
integer, take your pick.  

>Personally, I feel that any such overflow might occur in date manipulation 
>routines (adding, subtracting, etc) particularly in smaller word length 
>processor environments (16-bit for example). I cannot prove this, nor do I 
>wish to. I submit that as a pre-cursor to discussion only.

It is possible that something in *one* ANSI C implementation used
an int where a long should have been used.  This is not a problem
on systems with 32-bit or larger ints.  I'm also having trouble
imagining what overflows.  The number of *days* since January 1, 1970
isn't close to overflowing into the sign bit of a 16-bit int.

>I can assure you that my intention is purely research and by no means is 
>this query meant to provoke any kind of heated response or business-wide 
>'panic'. I simply need expert help.

Keith Thompson <kst-u@mib.org> writes:
> "Ade" <adrian.birkett@blueyonder.co.uk> writes:
>> Thanks all for your responses.
>>
>> Err... yes, I did mean "ANSI" and can't think why I spelt it incorrectly 
>> throughout - sorry.
>>
>> Some links that mention it...
>>
>> http://www.ugu.com/sui/ugu/showclassic?I=y2k.dates&F=0111111111&G=Y
>
> This mentions:
>
>     January 1, 2010 - Overflow ANSI C Library (Note: This event is
>     alleged to be a valid Y2K problem date. I do not have any
>     additional information on this claim)
>
> As far as I know, this is nonsense.
>
>> http://www.ismosys.com/downloads/general/Dates%20potentially%20causing%20computer%20problems.pdf
>
> This also says:
>
>     2010/01/01: Overflow for ANSI C library.

That's clearly the date I will fill the entirety of RAM on a 4GB machine 
with non-NUL characters, and run strlen on it.

> And:
>
>     2034/09/30: Overflow for UNIX time function.
>
> I can't figure out the significance of that date, and I don't believe
> there is any.

I suspect the nonsense density of that document is quite high.

Phil
-- 
Marijuana is indeed a dangerous drug.  
It causes governments to wage war against their own people.
-- Dave Seaman (sci.math, 19 Mar 2009)

"Gordon Burditt" <gordonb.z00b9@burditt.org> wrote in message 
news:INGdnRFFJ4a38qjXnZ2dnUVZ_qmdnZ2d@posted.internetamerica...
> >The company I work for has asked me to research the possibility of an 
> >ASNI C
>>runtime library overflow bug for 2010 in the date routines, specifically 
>>as
>>to whether it is a real problem or whether it was fabricated at Y2K time 
>>as
>>a means of further scare-mongering.
>
> ANSI C specifies very little about the date routines.  In particular:
>
> - It does NOT specify that a time_t is 32 bits.
> - It does NOT specify that a time_t represents a count of the number
>  of <insert some time unit here> since <fixed time>.  It especially
>  doesn't specify that a time_t represents a number of seconds.
> - It does NOT specify that if you subtract two time_t's, you get anything
>  meaningful.  Even the sign of the result is useless.  Try, for example,
>  subtracting 12311999 (December 31, 1999) from 01012000 (January 1, 2000).
>  You get -11299999, which doesn't mean much.
>
> There is no problem with "ANSI C date routines" in common; you have
> to specify a particular implementation.  "Cars will run out of gas
> by June 17, 2009".  Well, mine probably will if I don't fill it up
> first.
>
> A time_t could, for example, increment by one every time there's
> an earthquake in California.  For that, I guess you'd need a 128-bit
> integer.  A time_t could, for example, increment by one every time
> there's an earthquake in Texas.  With 5 in a week recently in or
> near one city, that might overflow an 8-bit integer faster than you
> think.
>
>>The reason I say scare-mongering is
>>because I can find no absolute description of a problem relating to this 
>>on
>>the internet (my biggest source of information). I can find many documents
>>that state it exists but no details and, funnily enough, they all seem to 
>>be
>
> Post the documents, or at least pointers to them.  I can do Google 
> searches
> too, but I want to see what *YOU* see.
>
>>cloned from an original source - the wording is normally exact.
>
> So let's see the exact wording.
>
>>If a problem does exist in the date routines of the ASNI libraries, does
>>anyone have any examples or theoretical papers on what may (or may not) be
>>the cause?
>
> The common implementation of time_t, as a 32-bit number of seconds
> since January 1, 1970 00:00 GMT, will overflow into the sign bit
> on Jan 19, 2038.  The obvious fix for this is to extend it to 64
> bits.  Many systems have already done this.
>
> The asctime() and ctime() routines have a Y10K problem, since the
> format for a printable date is specified as having 4 digits.  Someone
> might misinterpret Y10K as meaning 2010 instead of 10000.
>
> The struct tm element tm_year is subject to overflow (of either 16-bit
> or 32-bit integers) if you extend time_t to 64 bits as a number of seconds
> since January 1, 1970 0:00:00 GMT.  This first happens for the year
> 32768+1900 on a machine with 16-bit ints, unless time_t runs out first.
>
> There *is* a real 2010 time bug in NewtonOS on January 5, 2010, in
> some functions in NewtonScript.  This clock uses a number of seconds
> since January 1, 1993, and uses a 30-bit integer.  As far as I know,
> there is no implementation of C built on NewtonScript.  There is a
> (or maybe several) C++ implementation on NewtonOS; it uses (unsigned
> 32-bit) dates from 1904-2040 without problems.  Does your company
> depend on Apple Newtons to conduct its business?
>
> The GPS week number (0-1023) overflowed on August 21, 1999.  The
> next overflow is due about 19.6 years from then.  That's not close
> to 2010.
>
> There is a real problem representing the maturity date of a 28-year
> mortgage issued in 2010.  As far as I know, nobody issues 28-year
> mortgages.  30-year mortgages used to be common, and that overflow
> has already happened.  Banks used to have money, also.  Besides,
> banks want to represent the day, not the time, as time_t does funny
> things with time zones that don't jive with the way banks do business.
>
> Some economists are projecting the US national debt will overflow
> an integer in 2010.  That's a 64-bit, 128-bit, 256-bit, or 512-bit
> integer, take your pick.
>
>>Personally, I feel that any such overflow might occur in date manipulation
>>routines (adding, subtracting, etc) particularly in smaller word length
>>processor environments (16-bit for example). I cannot prove this, nor do I
>>wish to. I submit that as a pre-cursor to discussion only.
>
> It is possible that something in *one* ANSI C implementation used
> an int where a long should have been used.  This is not a problem
> on systems with 32-bit or larger ints.  I'm also having trouble
> imagining what overflows.  The number of *days* since January 1, 1970
> isn't close to overflowing into the sign bit of a 16-bit int.
>
>>I can assure you that my intention is purely research and by no means is
>>this query meant to provoke any kind of heated response or business-wide
>>'panic'. I simply need expert help.
>
>


Gordon,

Thanks for the detailled response, it's basically what I was looking for. I 
have posted a couple of links in my previous reply to a response and I'd 
appreciate your comments on them being seemingly cloned and altogether 
vague.

My company was contacted by a large customer which uses C code to control 
some, err..., let's just say, sensitive equipment, along with ADA, Pascal 
and Fortran. This code has to be re-certified after each change and so the 
costs of suddenly realizing that a potential problem might exist sent alarm 
bells ringing. I also have to add here that, although my question concerns 
ANSI-C based compilers in particular, the end platform might be Solaris, VMS 
or cross-compiled onto 68000 based chips/circuits depending on the 
application, very few of them rely on windows-based technology.

Thanks again,

Ade 

gordonb.z00b9@burditt.org (Gordon Burditt) writes:

> ANSI C specifies very little about the date routines.  In particular:
>
> - It does NOT specify that a time_t is 32 bits.
> - It does NOT specify that a time_t represents a count of the number
>   of <insert some time unit here> since <fixed time>.  It especially
>   doesn't specify that a time_t represents a number of seconds.
> - It does NOT specify that if you subtract two time_t's, you get anything
>   meaningful.  Even the sign of the result is useless.  Try, for example, 
>   subtracting 12311999 (December 31, 1999) from 01012000 (January 1, 2000).  
>   You get -11299999, which doesn't mean much.

It is, however, a common implementation choice for a time_t to
represent a number of seconds since the epoch, and in particular
it is a POSIX requirement.
-- 
Ben Pfaff 
http://benpfaff.org