|
PureBytes Links
Trading Reference Links
|
Well - what approach will a particular piece of software take? I don't know
about you - but I have data that I use for systems testing that goes back to the
1920's. So will my 2/1/27 data be read as 2/1/1927 - or 2/1/2027? Using
anything other than a 4 digit format could be ambiguous. Robyn
Scientific Approaches wrote:
> Gary Funck wrote:
>
> > While we're on the subject, do the various historical and
> > realtime datafeed providers have implicit Y2K compliant
> > problems as well?
>
> No, except where software makes wrong assumptions about the century. The
> use of two-digit years is common in our society. If you date a check
> 2/17/00 on February 17th of the year 2000 and your bank makes the wrong
> assumption that it was written February 17th of the year 1900, they will
> bounce it, because of the assumed stale date. However, the problem will
> have been due to their assumption, not your date.
>
> Except where trading data histories extend back into the early part of the
> 20th century, software can be written to make correct century assumptions
> from two-digit year dates. There will be no more need for trading data
> services to send four-digit years at the turn of the century than there is
> now. The same ambiguity exists now that will exist then. Did the 2/17/98
> date-stamp on the data you received today imply the year 2098, 1998, 1898,
> or 1798? How do you know? You know, because you know what century we are
> in. Won't you also know that a couple years from now? If so, couldn't your
> software "know" it also?
>
> -Bob Brickey
> Scientific Approaches
> sci@xxxxxxxxxx
|