|
PureBytes Links
Trading Reference Links
|
Robyn wrote:
> 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.
I wasn't suggesting software shouldn't be able to read four-digit Gregorian
year dates. It should. I also wasn't suggesting exceptionally long data
histories shouldn't have four-digit dates. They should, if a Gregorian
Calendar is used. I was addressing whether real-time and end-of-day data
providers need to do something different, because the century will change in
two years. They don't.
I have U.S. stock market data that extends back to January 3, 1861. It
doesn't have two- or four-year Gregorian dates, because the Gregorian
Calendar isn't well suited to days-between-dates calculations. I instead
use Astronomical Julian Day Numbers. They are what all professional trading
software should use to avoid a range of potential date problems.
However, these issues have little to do with the coming change in century.
It is a legitimate complaint that TradeStation can't read data files with
four-digit dates. Professional software should be able to do that. It is a
legitimate complaint that it can't read files with Julian dates.
Professional software should be able to do that also. However, there is no
logical reason to think real-time data feeds need to be changed, because of
the year 2000. There is no reason they should be changed. Everyone in the
world will know when the century changes. Will we or our computers need to
be reminded of the new century every minute of the day, twenty four hours a
day, for the next 100 years? I rather would have data feed services use the
available bandwidth to send price quotes more quickly than to use it to send
something everyone already knows, over, and over, and over again every
minute for the rest of my life.
-Bob Brickey
Scientific Approaches
sci@xxxxxxxxxx
|