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 suspect using a new
--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 obviously
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?
$ cal 11
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 to worry. The 11th of
platforms affected: all
distribution of threat: wide
severity of threat: potentially serious
leadtime: 6.3 years :)
I noticed one of my customers using the special date of 11/11/11 in
their database.
I've since realised this practice might be quite widespread, and
indeed warrants an alert
--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,
