Conference 7.286::digital

My customer has the year 2000 problems already shown up after this past
new year. The problem is with the credit cards expiration date.

The practice of credit card providers is to have for expiration date
equal the date the card issued plus 3 years which for new cards is
1997+3=2000

Again as in 0. old IBM mentality and a lot of unresponsibility. 
The justtification? Ahhh, lets do it the same way it is done on
the IBM side, not how DIGITAL is proposing.
I am not talking about some old code. It was this past AUG that
that they developed this appl and didn't want to listen.

George

  You are going to see lots of situations like this over the next year or
two. By a year from now, so many people will have credit cards with expir-
ation dates of 2000 or later that any merchant who doesn't have a fix in
place will lose huge amounts of business. In the meantime, the only safe
policy is if your credit card has an expiration date of 200, bring enough cash 
and travelers checks to cover all expected transactions.
  Does this problem also affect ATM cards?

    
    	I don't think ATM cards expire, as a rule.
    
    	Mine only gets replaced when it breaks in 1/2.
    

>    	I don't think ATM cards expire, as a rule.

My DCU ATM card has an expiration date.

My BayBank ATM card has an expiration date.

My Fleet ATM card has an expiration date.

/john

    
    	Strange, IMO.
    
    	My only ATM card is a Fleet/Presto/Cirrus 24.
    

    All of my cards (ATM & plastic money) have expiration dates.
    
    I have read somewhere (but I can't remember where) that some of the
    card companies have threatened to charge stores for cases where the
    stores software incorrectly rejects a card because it has an expiration
    date of 2000 and beyond.
    
    Antonio

Notefile: TURRIS::EASYNET_CONFERENCES
Note: 4593.0
Author: NSIC00::DIRKS
Topic: YEAR 2000 issues, services, and service delivery
Date: 20-DEC-1996 04:27
Shopping-List: SIOG::YEAR2000
	
	Location of conference: SIOG::YEAR2000

	This new conference deals with all topics relating to the upcoming
	YEAR 2000, date-related issues which could arise on Digital-based
	systems, and possible solutions/actions needed.

	The notes conference is started as a means to communicate between
	people in the field who have to sell or deliver services to our
	Customers relating to solving the Year 2000 'bug'.

Notefile: TURRIS::EASYNET_CONFERENCES
Note: 4594.0
Author: XDELTA::HOFFMAN "Steve, OpenVMS Engineering"
Topic: OpenVMS Year 2000 Issues: EVMS::Y2K
Date: 23-DEC-1996 11:32

   OpenVMS Year 2000 Issues: EVMS::Y2K

   The EVMS::Y2K notes conference is intended for general discussion of
   Year 2000 date-storage related issues in the OpenVMS environment, and
   as a clearinghouse for strategies and official statements, as well as
   information on known problems found in OpenVMS components and various
   discussions on potential remediations for these problems.

>	The notes conference is started as a means to communicate between
>	people in the field who have to sell or deliver services to our
>	Customers relating to solving the Year 2000 'bug'.

You don't solve a bug, you fix it. But since it's just one bug, what's the
worry?

    
    > I have read somewhere (but I can't remember where) that some of the
    > card companies have threatened to charge stores for cases where the
    > stores software incorrectly rejects a card because it has an expiration
    > date of 2000 and beyond.
    
    Ermmmmm, how are they going to find out ? If the supermarkets ATM
    rejects my card, the Card Co. won't receive any notification at all...
    
    Graham

unless maybe you tell the card company?

The article Antonio refers to said that they (the UK credit card issuers)
had delayed issuing 2000 expiry dates and after some date (March/April
this year) they would send round people to make test transactions and
anyone not able to accept the cards would be fined (1K pounds I think).

Real people get 2000 cards later.

Peter

    
    I wonder which is really more cost effective in the long run for the
    credit card (et al.) companies:
    
    1)  Losing business because they are sending out cards that cannot be
        used in many places, or
    2)  Changing to a 1-year expiration date and sending out new cards
        every year, delaying the Y2K snafus at the uncontrollable client
        sites until the last possible time...
    
    -Mike

:               -< This only happens once a millenium, luckily. >-

   Date bug variations occur at 1997 (10K), 1998 (GPS), 2000 (Y2K), 2038
   (C & UNIX), 2057 (OpenVMS), circa 2076 (C & UNIX), 10000 (DCL), and at
   various other dates.

    Anyone else remember DATE75 bugs in TOPS10??
    
    /Charlotte

    re: .14
    
    Yes!
    

    
    
    >Date bug variations occur at 1997 (10K), 1998 (GPS), 2000 (Y2K), 2038
    >(C & UNIX), 2057 (OpenVMS), circa 2076 (C & UNIX), 10000 (DCL), and at
    >various other dates.
    
    
    If you do any DCL coding that is still around in the year 10,000 I
    promise I will fix it no problem, ok?  ;^) 

Re: .13
>   Date bug variations occur at 1997 (10K), 1998 (GPS), 2000 (Y2K), 2038
>   (C & UNIX), 2057 (OpenVMS), circa 2076 (C & UNIX), 10000 (DCL), and at
>   various other dates.
    
    The US Naval Observatory has a statement about the GPS date rollover
    which (IIRC) basically says "that's the way it is; live with it; it's
    not a bug" - your h/w manufacturer basically needs to have some way of
    getting you to tell the h/w roughly what date it is!
    
    I'm intrigued about the 2057 OpenVMS date - what is that one? Is it
    Unix base date + 32000 days delta time?
    
    Antonio
    

:    I'm intrigued about the 2057 OpenVMS date - what is that one? Is it
:    Unix base date + 32000 days delta time?

   Nope, it's software on OpenVMS Alpha that's using the little
   known (and IMO, we never should have added it) two-digit-years
   feature, and passing the exe$gl_transition_year (`57') bias.
   See EVMS::Y2K notes 19.*, 20.*, 38.*, 51.*.

>    I wonder which is really more cost effective in the long run for the
>    credit card (et al.) companies:
    
>    1)  Losing business because they are sending out cards that cannot be
>        used in many places, or
>    2)  Changing to a 1-year expiration date and sending out new cards
>        every year, delaying the Y2K snafus at the uncontrollable client
>        sites until the last possible time...
    
  It is much better to have these snafus occur now than 2-3 years now. Our
only hope of avoiding a catastrophe in the first few weeks of 2000 is to begin
aggressively fixing the year-2000 bugs now. And it often takes loud customer 
complaints (non-functioning credit cards in this case) to get business people 
to act.

    The credit card SNAFUs will start in 1998, that's when my cards will
    have 00 expiration dates. Your cards may vary, but I'm only bothered
    about mine :-)
    
    By 1-JAN-2000 we'll be worrying about 747s landing on our houses and
    nuclear tipped missiles going into a sulk and VAX 8800 consoles being
    just a few years away from death etc.
    
    Antonio

    
    	And Windows '98 should be out by 2000, also.
    

Re: somewhere further back

I stumbled across yet another Y2K article in RISKS 18.91 which contained a
reference to an article in RISKS 18.74 which states (in part):

>Visa, the world's largest credit card company, is preparing to impose a fine
>of up to UKP100,000 per month on some of its member banks in a last-ditch
>attempt to ensure that they will accept credit cards with expiry dates
>extending into the new millennium.

>The company, itself a consortium of 20,000 banks, is launching the penal
>system a year after its first deadline for Year 2000 compliance.  It
>estimated that 1.3 million outlets worldwide are still unable to deal with
>cards with expiry dates reading '00'. Britain is believed to account for
>only 40,000 of the faulty terminals.

>After April, banks that have problems processing Visa's cards will be
>charged between UKP600 and UKP100,000 per month, depending on volume, until
>they correct the bug.

In Switzerland everyone has a social number of the following format:
NNN-YY-QDD-RRR. YY is the two_digit_year_of_birth.

Im wondering if they will stop paying pension to the (ok,few) people born in
1900 or if they'll start paying pension to all born in 2000...:-))))

andre 

    In Finland, the format DDMMYY-XXXC (XXX is a 'serial number', C a
    checksum). The system was introduced ages ago (in sixties I believe) so
    that there were plenty of people born before 1900. However, their
    format is DDMMYY+XXXC. I don't know what they've decided for 2000
    though.

Is Finland so small that it's impossible for more than 1000 people to be born
on one day?

    re .25: With a population of ~5 million, and a birth rate of ~12/1000,
    (average ~165/day) that would be very unlikely...
    
    Besides, the 'serial number' is odd for males, even for females, so
    more than ~500 of either gender would break the system too.
    
    Of course, if the Finns would decide reunificating Russia with its old
    motherland Finland, things would have to change... ;-)
    

Do they change the serial number for transsexuals?

ref. .-1 
yep the get the reciprocal of the originally assigned number..

I just bought a CD at DCU... the maturity date is the year 01.

<sigh>

    Let us know if you end up with more money, or less, when it matures...

    
    	I think you should buy 20 of them and cash them in tomorrow.
    

> I just bought a CD at DCU... the maturity date is the year 01.

The fact that the maturity year printed on a CD is two digits is in itself
not an indication of a problem.  The software could be using 4 digit years
internally, and simply printing the least two signficant digits on the CD.

    re .28
    
    So that means that you can only assign 1 of each odd/even number pair.
    Otherwise you might not have the other one free if it is needed.
    
    That you mean there are only 500 numbers available for each day ?
    
    Andrew

re: .23 .24

For pensions, etc. the real two-digit problem occurs when a 
person turns 100.  

You can deal with some of the two-digit Y2K issues by doing
something like: 

  if (current_year >= birth_year)
    age = current_year - birth_year /* ignoring where birthdate falls */
  else
    age = current_year + 100 - birth_year
  endif

Unfortunately, this breaks in the year a person turns 100.

Wes