On Wed, Jul 06, 2005 at 03:11:58PM -0500, Paul Schmehl wrote:
> >>Not to worry. The 11th of November, 2011 is a Saturday. No one will be
> >>working that day. :-)
>
> It was a joke. A *joke*. Did anyone *seriously* think I actually looked
> it *up*?
When it's so easy, why not?
$ ca
--On Wednesday, July 06, 2005 14:31:17 -0500 Ron DuFresne
<[EMAIL PROTECTED]> wrote:
On Sun, 3 Jul 2005, Paul Schmehl wrote:
--On July 4, 2005 12:03:02 AM +0100 lsi <[EMAIL PROTECTED]> wrote:
>
> For this customer 11/11/11 in the date field means, don't process
> this record, which will obvio
On Sun, 3 Jul 2005, Paul Schmehl wrote:
> --On July 4, 2005 12:03:02 AM +0100 lsi <[EMAIL PROTECTED]> wrote:
> >
> > For this customer 11/11/11 in the date field means, don't process
> > this record, which will obviously cause problems with legitimate
> > transactions on that date.
> >
> > I suspe
Of course, this is not a bug, but bad admin/dbadmin practise, for which
there are no patches available.
thanks,
Ron DuFresne
On Mon, 4 Jul 2005, lsi wrote:
> platforms affected: all
> distribution of threat: wide
> severity of threat: potentially serious
> leadtime: 6.3 years :)
>
> I noticed
I saw the same thing happen on 9/9/99
The company went through a flurry of data entry, and they seemed to ride
out the event well enough.
This may have been due to a few pointed warnings from the technical
staff. Then again, it may have been wrapped in with the changes for the
2000 'bug', so
On Mon, 04 Jul 2005 00:03:02 BST, lsi said:
> I noticed one of my customers using the "special" date of 11/11/11 in
> their database.
*yawn*. IBM mainframe systems coded expiration dates on the machine-readable
volume labels on tapes in a YYDDD format. One popular tape management system
from
>
> I noticed one of my customers using the "special" date of 11/11/11 in
> their database.
These sort of shortcuts are frequently taken by the programmers or the
DB admins after the whole system has been setup :)
> For this customer 11/11/11 in the date field means, don't process
> this record,
>>> For this customer 11/11/11 in the date field means, don't process this
>>> record, which will obviously cause problems with legitimate
>>> transactions on that date.
>>>
>>> I suspect using a new field to flag a state, instead of "special"
>>> data, would have been more appropriate.
>>>
>Not
--On July 4, 2005 12:03:02 AM +0100 lsi <[EMAIL PROTECTED]> wrote:
For this customer 11/11/11 in the date field means, don't process
this record, which will obviously cause problems with legitimate
transactions on that date.
I suspect using a new field to flag a state, instead of "special"
data
