Pythonic Y2K

[Avi Gross]

Larry,

I keep hearing similar things about the Flu Vaccine. It only works 40% of
the time or whatever. But most of the people that get the flu get a
different strain they were not vaccinated against!

There are hundreds of strains out there and by protecting the herd against
just a few, others will flourish. So was it worth it?

Your argument would be that your work found lots of things related to Y2000
that could have been a problem and therefore never got a chance to show. I
wonder if anyone did a case study and found an organization that refused to
budge and changed nothing, not even other products that were changed like
the OS? If such organizations had zero problems, that would be interesting.
If they had problems and rapidly had their software changed or fixed, that
would be another and we could ask if the relative cost and consequence made
such an approach cheaper.

But in reality, I suspect that many of the vendors supplying products made
the change for all their clients. I bet Oracle might have offered some
combination of new and improved products to replace old ones or tools that
could be used to say read in a database in one format and write it out again
with wider date fields. 

The vast difference some allude to is realistic. Y2K swept the globe in
about 24 hours. No easy way to avoid it for many applications. Someone
running python 2.X on their own machines may be able to continue living in
their bubble for quite a while. If you sell or share a product with python
frozen into an app, it makes no difference. But asking some clients to
maintain multiple copies of python set up so one app keeps running as all
others use the newer one, may not remain a great solution indefinitely. 

Has anyone considered something that may be at the edges. How well do
cooperating programs work together? I mean if program one processes and
saves some data structures using something like pickle, and program two is
supposed to read the pickle back in and continue processing, then you may
get anomalies of many kinds if they use different pythons. Similarly,
processes that start up other scripts and communicate with them, may need to
start newer programs that use the 3.X or beyond version as no back-ported
version exists. The bubble may enlarge and may eventually burst.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net at python.org> On
Behalf Of Larry Martell
Sent: Friday, January 18, 2019 10:47 AM
To: Python <python-list at python.org>
Subject: Re: Pythonic Y2K

On Fri, Jan 18, 2019 at 10:43 AM Michael Torrie <torriem at gmail.com> wrote:
>
> On 01/16/2019 12:02 PM, Avi Gross wrote:
> > I recall the days before the year 2000 with the Y2K scare when 
> > people worried that legacy software might stop working or do 
> > horrible things once the clock turned. It may even have been scary 
> > enough for some companies to rewrite key applications and even switch
from languages like COBOL.
>
> Of course it wasn't just a scare.  The date rollover problem was very 
> real. It's interesting that now we call it the Y2K "scare" and since 
> most things came through that okay we often suppose that the people 
> who were warning about this impending problem were simply being 
> alarmist and prophets of doom.  We often deride them.  But the fact 
> is, people did take these prophets of doom seriously and there was a 
> massive, even heroic effort, to fix a lot of these critical backend 
> systems so that disaster was avoided (just barely).  I'm not talking 
> about PCs rolling over to 00.  I'm talking about banking software, 
> mission critical control software.  It certainly was scary enough for 
> a lot of companies to spend a lot of money rewriting key software.  
> The problem wasn't with COBOL necessarily.

I had one client, a hedge fund, that I fixed literally 1000's of Y2K issues
for. When Y2K came and there were no problems, the owner said to me "You
made such a big deal about the Y2K thing, and nothing happened."
--
https://mail.python.org/mailman/listinfo/python-list