Y2.01K bug in other equipment & 2026
Chris Evans
Dubbed by www.theregister.co.uk 'The Y2.01K bug' the start of the new year
has hit other equipment as well as the Iyonix!
***
A new year bug has scuppered card transactions at thousands of Australian
shops for four days so far, because systems at the Bank of Queensland say it
is now 2016.
***
Symantec's Endpoint Protection Manager has been hit by a classic date bug
and fell over at the end of the year, accepting no definition updates dated
since then.
Symantec have issued a statement, which states that: "An issue has been
identified in the Symantec Endpoint Protection Manager (SEPM) server whereby
all types of SEP definition content [AV/AS, IPS] with a date greater than
December 31, 2009 11:59pm are considered to be 'out of date'."
***
The date bug which is interfering with Aussie point of sale transactions has
spread to some Windows mobile phones. The glitch means that text messages
received since New Year's Eve will appear with a 2016 date!
***
Also one user reports "My Nokia N97 has failed to display any photo taken since
New Year in the photo album app. They're on the device as I can pull them
off by browsing the file system."
I recall around the time of the Y2K hype that 2026? was reportedly going to
be a big problem. I think it was to do with the UTC counter wrapping round.
Has a fix been found for that?
Chris Evans
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!
Steve Fryatt
<ant05173...@client.cjemicros.co.uk>:
> I recall around the time of the Y2K hype that 2026? was reportedly going
> to be a big problem. I think it was to do with the UTC counter wrapping
> round.
2038 -- it's when the 32-bit Unix representation of time wraps around (as
the 40-bit RISC OS one does in 22-something-or-other). It also affects
anything that uses a similar format (such as, I suspcect, some RISC OS
software).
> Has a fix been found for that?
AIUI, there seems to be a move towards 64-bit time storage on new systems.
Obviously existing systems will still have the problem, and I'm not familiar
enough with the issue to know what is being done.
--
Steve Fryatt - Leeds, England
Rob Kendrick
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> > Has a fix been found for that?
>
> AIUI, there seems to be a move towards 64-bit time storage on new
> systems. Obviously existing systems will still have the problem, and
> I'm not familiar enough with the issue to know what is being done.
All modern UNIX systems have had a 64 bit time_t for a decade. If
people are still running 40-year-old software by the time it becomes a
problem, it's their own fault. (I can't think of very much 40-year-old
software that's still running today.)
B.
Jeremy Nicoll - news posts
> I recall around the time of the Y2K hype
<bee in bonnet>
It wasn't hype. Lots of work was done to prevent otherwise inevitable real
problems.
I don't really understand why you think that's not the case.
Of course, the media reported it as a non-event because there'd been no big
problem, but that's just stupid. There was no big problem because, with
lots of warning, organisations did a proper professional job preparing for
and simulating the change, until they were as sure as they could be that
it'd all be ok.
</>
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "nnn" by "284".
Chris Evans
Jeremy Nicoll - news posts <URL:mailto:jn.nntp....@wingsandbeaks.org.uk> wrote:
> Chris Evans <ch...@cjemicros.co.uk> wrote:
>
> > I recall around the time of the Y2K hype
>
> <bee in bonnet>
>
> It wasn't hype. Lots of work was done to prevent otherwise inevitable real
> problems.
>
> I don't really understand why you think that's not the case.
I readily admit it was a significant problem and could have caused chaos[1]
if it hadn't been addressed.
Though as is normal with the media it wasn't reported in a balanced way and
came over as hype.
[1] How much chaos would have occured is impossible to quantify.
> Of course, the media reported it as a non-event because there'd been no big
> problem, but that's just stupid. There was no big problem because, with
> lots of warning, organisations did a proper professional job preparing for
> and simulating the change, until they were as sure as they could be that
> it'd all be ok.
There is a problem now that the public and non technical business bosses
believe it wasn't the problem that was reported and will in future not take
seriously other potential threats.
Stewart Brodie
> In article <gemini.kvsmg...@wingsandbeaks.org.uk.invalid>,
> Jeremy Nicoll - news posts
<URL:mailto:jn.nntp....@wingsandbeaks.org.uk> wrote:
> > Chris Evans <ch...@cjemicros.co.uk> wrote:
> >
> > > I recall around the time of the Y2K hype
> >
> > It wasn't hype. Lots of work was done to prevent otherwise inevitable
> > real problems.
> >
> > I don't really understand why you think that's not the case.
>
> I readily admit it was a significant problem and could have caused
> chaos[1] if it hadn't been addressed.
>
> Though as is normal with the media it wasn't reported in a balanced way
> and came over as hype.
Many organisations were trying to make people aware of the problem in the
early 1990s (and some even earlier), but the media ignored them.
In the end, as the end of the 1990s approached, the "experts" realised that
they had to change their approach, so they started announcing all sorts of
impending cataclysmic events that might occur if nothing was done. That got
the media's attention.
I imagine exactly the same will happen in the mid-2030s.
--
Stewart Brodie
Peter Naulls
http://en.wikipedia.org/wiki/Year_2038_problem
On most Linux systems, time_t remains 32-bit. For 64-bit systems, it's
64-bit, so a lot of problems can be mitigated by "just" recompiling
and using a 64-bit system instead (most PCs for quite some time have
been able to run 64-bit Linux). But as the article notes, the problems
are with directly stored 32-bit values, although modern databases would
use a better format, which avoids this.
However, as the article notes, there are millions of embedded 32-bit
devices out there, including ARM, where it remains 32-bit.
So, the assumption is perhaps by that time we'll have 64-bit systems
at least everywhere, but as COBOL from the 1960s shows, that may
not be a safe assumption at all.
time_t in UnixLib remains 32-bit, but could probably safely at this
point be made 64-bit with the ELF release, since there's no real legacy
code about that this would cause binary compatibilities with, although
I suspect there is the occasional bit of RISC OS code which assumes
it is 32-bit.
jeff
>
> On most Linux systems, time_t remains 32-bit.
On the Norcroft ARM compiler time_t is unsigned, which gives us an
extra 68 years.
(Unix time zero is 1970, but time -1 is 1969)
On unix systems with signed time_t I use the following trick:
#define YEARS_28 (((365*28)+7)*24*60*60)
struct tm *mylocaltime (const time_t * timer)
{
unsigned int offset;
time_t tcopy;
struct tm * tptr;
offset = 0;
tcopy = *timer;
while (tcopy < 0)
{
tcopy -= YEARS_28;
offset += 28;
}
tptr = localtime (&tcopy);
tptr -> tm_year += offset;
return (tptr);
}
Which rather clumsily gets up to 2099 (Becase 2100 is not a leap
year).
Jeff
Mark Wiggin
Rob Kendrick <nn...@rjek.com> wrote:
I'm sure that there's someone out there who knows of some! ;-)
> B.
--
Mark Wiggin
Rob Kendrick
Mark Wiggin <mark....@blueyonder.co.uk> wrote:
> > All modern UNIX systems have had a 64 bit time_t for a decade. If
> > people are still running 40-year-old software by the time it
> > becomes a problem, it's their own fault. (I can't think of very
> > much 40-year-old software that's still running today.)
>
> I'm sure that there's someone out there who knows of some! ;-)
Untouched, 40-year-old, date-handling code? I suspect that's
vanishingly unlikely :)
B.
druck
> Untouched, 40-year-old, date-handling code? I suspect that's
> vanishingly unlikely :)
I bloody well hope not, come 2037 that's my retirement fund!
Earn a few quid fixing that and I might be able to afford put my feet up.
---druck
Rob Kendrick
Good idea. Perhaps it's time to start paying into this retirement
fund, by way of sneaking these bugs into software now? :)
B.
Simon Smith
In message <1ca6e1d...@blueyonder.co.uk>
Mark Wiggin <mark....@blueyonder.co.uk> wrote:
Batch processing as used by banks. While these programs have to handle
staggeringly large numbers of records, on the whole they're conceptually
simple, stable, bug-free, and mostly written in COBOL. There's no particular
reason /to/ change them, and the costs associated with doing so would be
staggering (I shudder to think at the risks of reintroducing bugs that any
rewrite would provoke), so these programs are likely to keep chugging along
largely unaltered for as long as we have bank accounts. Yes, it's a niche,
but it's an important niche, and one that keeps a lot of processing power
and storage space gainfully occupied, and will do for decades to come.
--
Simon Smith
When emailing me, please use my preferred email address, which is on my web
site at http://www.simon-smith.org
Rob Kendrick
Simon Smith <simon_sm...@zen.co.uk> wrote:
> > > All modern UNIX systems have had a 64 bit time_t for a decade. If
> > > people are still running 40-year-old software by the time it
> > > becomes a problem, it's their own fault. (I can't think of very
> > > much 40-year-old software that's still running today.)
> >
> > I'm sure that there's someone out there who knows of some! ;-)
>
> Batch processing as used by banks. While these programs have to handle
> staggeringly large numbers of records, on the whole they're
> conceptually simple, stable, bug-free, and mostly written in COBOL.
Of course, if they're bug-free, there'll be no problem in 2038 :)
B.
Nick Roberts
Simon Smith <simon_sm...@zen.co.uk> wrote:
To a great extent it is exactly these same systems that would have hit
any issues with the Y2K problem. Having hit the problem once, I would
have hoped that they would have had enough forethought to have
anticipated the next potential problem date and tried to future-proof
their systems.
OTOH, these are the same institutions that have recently been
demonstrated to have shown a significant *lack* of forethought, so
maybe I'm imputing too much intelligence to them.
--
Nick Roberts tigger @ orpheusinternet.co.uk
Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.
Jeremy Nicoll - news posts
> In message <53c502d85...@zen.co.uk>
> Simon Smith <simon_sm...@zen.co.uk> wrote:
>
> > In message <1ca6e1d...@blueyonder.co.uk>
> > Mark Wiggin <mark....@blueyonder.co.uk> wrote:
> > > I'm sure that there's someone out there who knows of some! ;-)
I'm sure I read of a still in-use system somewhere quite recently that only
stored 1-digit dates. I can't remember what it was used for.
> > Batch processing as used by banks. While these programs have to
> > handle staggeringly large numbers of records, on the whole they're
> > conceptually simple, stable, bug-free, and mostly written in COBOL.
> > There's no particular reason /to/ change them, and the costs
> > associated with doing so would be staggering (I shudder to think at
> > the risks of reintroducing bugs that any rewrite would provoke), so
> > these programs are likely to keep chugging along largely unaltered
> > for as long as we have bank accounts. Yes, it's a niche, but it's an
> > important niche, and one that keeps a lot of processing power and
> > storage space gainfully occupied, and will do for decades to come.
>
> To a great extent it is exactly these same systems that would have hit
> any issues with the Y2K problem.
Yes, and where I worked /every/ program in that category got at least a
partial rewrite - of the date handling parts anyway. And yes, it cost a
great deal and employed hundreds of staff for about 18 months.
And, 'normal' development work was frozen, huge amounts of extra system and
application testing was done, and actually quite a lot of the program source
changes were done by automated systems, not all in-house. Hardly
surprisingly, some of the big software houses had realised they could get
Y2K related work if they had semi-automated solutions written and staff to
run them. Of course the out-sourced work was tested by the contract staff
involved, but only up to a point with fake data.
But testing individual programs or subsets of them wasn't the whole issue.
The normal running of thousands of separate programs within a day's or
week's processing had also to be tested. In practice we had to run
realistic full workloads (with large amounts of fake data) for days at a
time. As suites of programs were migrated from pre-Y2K to post-Y2K testing
some of the data had to be changed in step, but not much of it. IIRC we
typically ran a model of a whole week of processing, once per real week. The
files and databases at the end of that period were archived and the whole
test system reset in readiness for the next virtual week.
It didn't help that the Y2K change happened at the end of a year, because -
naturally - there was extra processing that happened at and near-to year-end
anyway. I believe we also ran lots of testing to simulate the Jan/Feb
transition, and the tax-year-end in April 2000, and the following year-end
(ie 2000/2001) processing. Probably some other times too.
But contrary to what most people expect the conversion work DID NOT change
stored 2-digit dates into 4-digit ones. That's not practical, because as
soon as you do you have to change every other program that reads the files
whose format you just changed. And they also have to read & write date
values & the whole problem snowballs.
You still have to have programs that process the old-format files because
you have at least 7 years' worth of archived data (mainly because of tax
regulations that affect your customers). Lots of the old data is on-site
and lots more is off-site. Changing the old files in all locations is too
big a risk as well as being wildly impractical.
What was done was to change on a date-field by date-field per file basis the
way the stored year number was interpreted. You could no longer say that a
file that stored "92" meant 1992; it depended on the specific use of that
field in any program that read or wrote the value.
In some programs, running in 2010, "92" in a particular field would mean
1992 whereas in the same program another field might mean "2092". In other
fields the run-date of the program would be irrelevant (perhaps because the
programs only implemented some financial product that had been available
until - say - 1980). Chunks of code that applied the field-specific logic
got merged into the source of the programs concerned (I think that fields
got read in 2-digit form, converted to the implied 4-digit one for program
logic only if that was required, then subsequently converted back to the
2-digit form applicable to the field in question before being rewritten to
file).
This method did have some consequences to customers aged more than 100.
They were specifically identified and special arrangements made (I don't
mean a hitman!) for any issue where the programmed solution would cause a
problem for them. That probably means they were 'bought off' in some way.
> Having hit the problem once, I would have hoped that they would have had
> enough forethought to have anticipated the next potential problem date and
> tried to future-proof their systems.
For our organisation, new application suites inevitably used 4-digit dates.
I don't think the solution used for the files described above would fail
later, the "interpretation of fields" logic rolled forward year by year.
> OTOH, these are the same institutions that have recently been
> demonstrated to have shown a significant *lack* of forethought, so
> maybe I'm imputing too much intelligence to them.
It's not the programming staff who screwed up the finances.
Martin
<gemini.kw5y9...@wingsandbeaks.org.uk.invalid>,
Jeremy Nicoll - news posts <jn.nntp....@wingsandbeaks.org.uk>
wrote:
> Nick Roberts <tig...@orpheusinternet.co.uk> wrote:
> > In message <53c502d85...@zen.co.uk>
> > Simon Smith <simon_sm...@zen.co.uk> wrote:
> > To a great extent it is exactly these same systems that would have hit
> > any issues with the Y2K problem.
> Yes, and where I worked /every/ program in that category got at least a
> partial rewrite - of the date handling parts anyway. And yes, it cost a
> great deal and employed hundreds of staff for about 18 months.
[Snip long description of coping with Y2K problem]
I have to say I agree with absolutely everything Jeremy wrote in his
detailed explanation, as it was exactly my experience, even in a small
pensions organisation.
There were hundreds of different types of dates, each of which could
cause chaos, which had to be analysed and programs changed. But in some
cases, the correct long-term technical solutions were vetoed due to lack
of time or money, which really came down to lack of business acceptance
early enough that there was a problem. These will eventually bite back.
I vividly remember being offered mince pies sometime in September 1999
'because it was Christmas!' ... the testing had rolled forward the
systems to that date!
The *big* Y2K problem, was that when 1/1/2000 came and few problems were
seen by the general public, they did not believe there had been a problem
at all! Believe me, there would have been MASSIVE problems without all
the enormous amount of work to reduce and remove most of the problems.
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
Nick Roberts
Jeremy Nicoll - news posts <jn.nntp....@wingsandbeaks.org.uk> wrote:
[Y2K bug]
> Nick Roberts <tig...@orpheusinternet.co.uk> wrote:
>
> > Having hit the problem once, I would have hoped that they would
> > have had enough forethought to have anticipated the next potential
> > problem date and tried to future-proof their systems.
>
> For our organisation, new application suites inevitably used 4-digit
> dates. I don't think the solution used for the files described above
> would fail later, the "interpretation of fields" logic rolled forward
> year by year.
>
>
> > OTOH, these are the same institutions that have recently been
> > demonstrated to have shown a significant *lack* of forethought, so
> > maybe I'm imputing too much intelligence to them.
>
> It's not the programming staff who screwed up the finances.
The problem is that the people with the funding for development and
maintenance are the mid- and senior managers, and they /are/ the people
who screwed up the finances. If they're interested in short-term
savings, then they could decide to do the job on the cheap, rather than
properly.
As a case in point: about 5 years ago, a major customer decided he had
no immediate need of a particular (very complex) piece of specialist
software, so pulled all the funding. I warned him that the need would
come back, and that the cost of providing minimal funding on a "care
and maintenance" basis to keep developer expertise current would pale
into insignificance beside the bill if we had to resurrect it from
cold.
Two years ago we had to resurrect the program, and, as expected, it
cost a fortune. The same customer had the nerve to demand why I hadn't
warned him about it. Luckily, I still had soft copies of the original
email discussion.