I do not give forecasts of general and social consequences; do not ask.
2007-01-21 : Some dead links are now underlined.
The date formats used on perishable goods, etc., are often capable of misinterpretation.
This affects all dateable, perishable consumer goods, and other general information; but I'll consider mainly food below. The prime concern here is with interpretation by the end user, the final opener of the customer-oriented package, who will be reading the item by eye, without a computer.
The few medicinal products that I had to hand were dated unambiguously, with one exception for which the century was nominally indeterminate (Year as YY).
Batteries are also dated; I had some "AA" cells marked "7/02", presumably July 2002. Road Works signs sometimes use YY dates.
Steve Adams lists some examples.
The problems of century rollover, as such, with "xx" being taken as "19xx" in lieu of "20xx", are now well-known, and really are only directly important within the trade.
However, the problems of ambiguity may not be so obvious. Remember that the expiry dates on food packets will be read not only by the trade, but also by consumers of all ages, some of whom may be calendrically naive. Where fewer than three of the fields Y, M, D are given, it may well be unclear whether Y or D is included, if 2 digits are present; and which field is M may also be doubtful.
Of two packets which I recently (1999-08-30) bought from a UK store, one is marked "display until end APR 00 best before end JUL 00"; the other is marked "display until AUG 31 use by SEP 01". In this case, the figure values make all clear, but later on they will not always do so. The wording, if considered, makes the situation more or less plain, but I suspect a bout of Y2k-type problems coming up before very long.
For example, in August 2001 Great-Aunt Agatha might find herself in possession of an item dated in days, in the second style above, SEP 01 and SEP 02; and, interpreting it as dated in years in the first style, might decide to keep it for Christmas. Or I might.
Alternatively, food dated JAN 01, meaning JAN 2001, may be wrongly thrown away after 2000-01-01.
It gets worse if any of the all-digit formats YY MM, MM YY, MM DD, DD MM are in use. 1999-09-25 : I've just finished a pack of 4 Birds Eye Beef Burgers, dated "Best Before End 12 00" - clearly Dec 2000 - but it looks as if burgers two months younger will be marked "02 01" meaning "Feb 2001", but capable of misinterpretation as "2nd Jan", "2002 Jan", or even "Feb 1st". 1999-09-29 : However, a new packet is marked "Best Before End 01 2001".
Having three fields does not guarantee safety : I had an empty packet here from Iceland (NOT a foreign country) which is marked "Keep frozen ... best before 28 JAN 00". It seems that subsequent ones may appear labelled 01 JAN 01, then 02 JAN 01, which should poison some ISO 8601 fans & orientals (we have a lot of Koreans around here). I have a "Best Before 12 01 01" stew tin (→2001-01-12?), an "07 OCT 01" tin of chicken, and a "MAR 03" (→2003?) tin of peas.
Use of full ISO 8601 dating, YYYY-MM-DD or YYYY month DD, would prevent error.
Again, it is the end-user, who may not even be the purchaser, who must be chiefly considered. The trade should understand the dating. But the risk will extend to badly-organised small businesses; and if a shop manages to sell aged goods for this reason, the user's interpretation may be influenced on the basis that the food must have been in-date when bought.
Reports from the USA imply that date-interpretation problems with end-user packaging are also possible there, though perhaps less likely.
DdL has pointed out that any supply-chain disruption in Jan'00 may lead to some rooting in the backs of cupboards. However, much ambiguity does not appear till '01 : a true Millennium Bug!
I recall, long ago, when being given a meal by a kind older friend, accepting an offer of having walnuts shaken from a packet on to my sweet course. Alas, the walnuts were time-expired; but the resulting maggots seemed to be enjoying their new freedom ...
There are UK labelling regulations - NEODA.
My reading of the above is that :-
Point-of-Sale bar codes (EAN) on packaging intended for the user do not hold date information. But those on warehouse "outers" do or can do so.
Subject : Y2k - User Misinterpretation of Food Expiry Dates
Confusion between two digits meaning Year 20## and meaning Year 19## is well understood; misidentification of ## fields in dates between Y, M, D has been discussed in Y2k newsgroups; the food trade will understand the date formats on their products.
However, one problem is perhaps not well-realised : the use of ## fields in expiry dates on the packaging of foods, together with the circumstances of domestic food storage, leads to the probability that many of those who finally use these packaged foods may misunderstand the dating formats.
For example, an item sold in March 2000 may be marked for use by "OCT 01" - does it have a six- or an eighteen- month life? If it is discovered in the back of the cupboard on 2000-09-20, should it be eaten soon, or is there a safe year left? Many errors can be expected.
Remember that some food travels, some amateur cooks travel, date formats vary, ...
If the famed cook, Great-Aunt Philomena o'Kerry, on her first trip ever out of Erin, visits the kitchen of her Great-Niece in Troy, AL, USA, will she be safe?
John Stockton, Surrey, UK.
<URL: >
Waitrose milk appears to be marked with the minute of expiry : on 1999-09-21 I bought a pint marked "26 SEP 11:03". Stork appears similarly marked.
One might also wonder about possible interpretations of dates with actual Y2k errors : "FEB 1901" has been reported, probably from USA, and, with bad print, might be taken as "Feb 19, '01" - actually about right.
1999-12-29 : within 4Q99, ISTM that the ambiguity of such markings in the local shops has substantially diminished.
I am not a lawyer.
It is utter folly to rely on any advice given by those in different jurisdictions from oneself.
For example, those in the UK are subject to EU law (in part as interpreted by the UK) and to UK law (except for Americans, who are everywhere also subject to the full rigor of US law).
Moreover, UK law is not homogeneous. Scots law and English law have always differed; and we have a separation of powers between the UK Parliament and Ministers and the local powers of the more-or-less corresponding bodies in Scotland, Wales, and Northern Ireland. Also hereabouts, but not in the UK, are the Crown Dependencies : the Isle of Man, and the Channel Islands.
It is also generally folly to rely on advice given on the Net, especially if the author is anonymous, un-located, or there is no particular reason to trust his or competence and integrity; but it should be safe if it comes from a reputable, identified, UK lawyer and your circumstances truly match the question.
I am not a lawyer.
Law is specific to the jurisdiction. The law relating to contracts and the law relating to liability for negligence would not even happily survive a move across the border to Scotland, never mind to the US.
Even great apparent similarity is dangerous, since, in any particular context, and where a real question arises, a tiny difference in the facts can mean a complete difference in the answers available.
... Except, of course, that we all now trade in each others jurisdictions.
David Swarbrick, Solicitor
Including the end of 2000.
The Year 2000 was a Leap Year, and therefore its final day was the 366th, and not the usual 365th. In particular, any system which experienced problems around 2000-02-29 required recheck for 2000-366.
When that previously happened, in 1996, there was at least one expensive failure caused by the 366th : the Tiwai Point Smelters. Some engines on Norwegian Railways seemingly missed 2000-366 - see Risks Digest 21.18. I've seen a report that AOL's news-server had the same fault; and that an IBM controller wouldn't load on 1980-366.
The Calendar Year 2000 started on a Saturday and finished on a Sunday, therefore requiring 54 weeks or part-weeks on a Sun..Sat calendar; this happens (in 1901..2099) at 28-year intervals. It could have an unexpected effect; all other calendar years require exactly 53 weeks or part-weeks (52 is clearly insufficient for 52×7+1=365 days). The situation occurs equally often for weeks starting on any other day; but does not apply under the ISO 8601 definition of Week Number. Risks Digest 21.19.2, and 54 Weeks in 2000 : Another Y2K Problem!, refer. The year 2012 has the same property for Mon..Sun weeks.
The Year 2000 had the first year-end of the 2000's; the first for which Y2k problems can occur in past data.
Years 1999 & 2000, represented as "99" & "00", could have been used as marker values.
There was no Leap Second at the end of 2000.
The Year 2000 actually ended the Second Millennium; the first year of the Third Millennium is 2001.
Slapdash Y2k fixes that forced the year to 2000 failed after December 2000.
Check that 2001-02-29 is invalid, and that 2001-03-01 follows 2001-02-28.
Within the years 2001..2031 (and especially in 2001..2012), when using the two-digit year formats YY/MM/DD, DD/MM/YY, MM/DD/YY, it is no longer generally possible to recognise the year field by its magnitude. Use ISO 8601 YYYY-MM-DD.
"MAR 01" could mean the First of March, or March 2001 - see food, above. In the UK, D M Y order seems standard for this.
For those parking for late celebrations : be warned that Low Tide in London is at about 2300h on 2000-12-31. This should catch some parking beside Richmond Bridge for a few hour's jollities, as the water rises; and elsewhere. But the Moon nears First Quarter then, so tides will only be Neap.
The pattern 010101 has been reported as an "unknown DoB" marker.
Financial Year 2000-2001 ends with April 5th, 2001. It is not a Leap Year, having only 365 days.
Major Y2.001K disaster in the first year of the Third Millennium seems rather unlikely; but there is still room for embarrassing error. See critdate.htm#Y2001 & other pages.
Indeed, there are a number of US reports suggesting that slapdash Y2k fixes have failed in 2001. There may be a Y2k+1 field-order bug in Excel with Format$(Now, "yy/mm/dd"), visible from 2000-01-02; a UK user has reported, in news:uk.tech.y2k, other post-Y2k VBA errors in XL-97 SR2, including what seems to be MYD for YMD.
Risks Digest, 21.18.3, 21.19.14-15, reports a model of Electronic Organiser that cannot handle YY in [01..49], any century.
Other possible problems during 2001 include the US DST start in April (MS VC++ RTL error?), and the UNIX One Gigasecond Rollover (and JavaScript/Java Terasecond) on Sunday September 9th.
On 2001-09-09 at 01:46:40 GMT is 1000000000 seconds UNIX time_t; the count will no longer fit into 9 decimal digits. REXX is said to default to 9. Problem reported in old Veritas software. Problem reported from Italy in a medical application (Risks Digest 21.69, 7/17). Some (UK Demon DIS type) News/Mail software needed update.
See Critical and Significant Dates.
Ambiguities :-
See Date Formats.
In news:uk.tech.y2k on 22 Sep 1999, C. Newport wrote :-
One potential y2k problem which many people will have overlooked :-
The CMOS battery in most PCs has a finite life, and current is only drawn from them when the machine is switched off. Many companies are closing for 2 weeks, so we should expect a good few of these batteries to have failed during the 2 week holiday.
This simple fault will, of course, be mis-diagnosed as a y2k failure. It might be a good idea to wander around the office and replace the batteries in all PCs which are more than 4 years old as a pre-emptive measure.
An exact type match will not be essential; but match the voltage and, if possible, the chemistry.
Can anyone offer reliable URLs relevant to CMOS/RTC battery care and replacement in PCs?
When describing hardware internals, it should help to use "Calendar" in preference to "Clock" whenever possible; there are too many other clocks.
We are, of course, really talking about the "Century Bug", in which, a year prior to the end of the Century, the last 2 digits of the year go from "99" to "00". If we had a true "Millennium Bug", in which, a year prior to the end of the Millennium, the last 3 digits of the year go from "999" to "000", then a 400-year setback would be, on the Gregorian Calendar, ideal.
The better known critical dates, such as 2000-01-01 and 2000-02-29 are, of course, obvious trigger-dates for true computer viruses; so do a virus-scan before running Y2k testers. It has also been suggested than a virus might unintentionally have a Y2k bug.
Y2k being a Time of Confusion, watch out also for fraud.
It is reported that the Intel P3 board with 3 memory slots often jumps from 1999 to 2099 on boot, perhaps about 25% of the time; the affected models have not necessarily all been withdrawn.
(URLs for these are solicited) Often with format and field-size changes, etc., in :-
Seen on Westergaard Year 2000, dated 1999-12-10 :-
Special Features Book Review
Today Westergaard Year 2000 reviews a new book by one of the first people to warn the U.S. federal government about Y2K, Jefferey Modic. Cowritten with Bayard Stockton, 'Nothing to Fear' is a novel Y2K novel that explores the relationship between the rose-tinted government press releases that have inundated the media's coverage of Y2K and the public's need to be told the real story.