[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Y2k patch- CAUTION "date"function



PureBytes Links

Trading Reference Links

  Seems to me that the root of this problem is "What does "date" return
in EL? Even with a y2k patch, I don't see how any function could return
a value in 2 different formats. It seems you could only have YYMMDD
or YYYYMMDD returned, not both. There would have to be a totally new 
and separate "dateX" function added to TS4 EL. i.e."date2k" or "date4Y"
etc...
  Therefore, until a new and separate built-in date function is created by
Omega for TS4, or the old one is replaced with the 4-digit YYYY portion
(rendering any code expecting YY to be returned non-readable) we're
stuck with one or the other and apparently, it's the old format.
  My guess is that y2k compliant for TS4 means that data can be read 
by TS4 without crashing it and that and 2000 dates are recognized as
being beyond 1999.
  So it's my guess that in TS4 EL code, 0000 will still be recognized as
less than 1999 unless you tell all you EL code that it's not.

dave stanley

dave stanley


============================

<< 
 > what happens if you add some number of days to a date?
 >   juliantodate(datetojulian(991231)+1)
 > or
 >   juliantodate(datetojulian(19991231)+1)
 > or
 >   juliantodate(datetojulian(000101)+1)
 > or
 >   juliantodate(datetojulian(20000101)+1)
 
 Good question - have not tried that, BUT I just tried entering in one of
 my studies a 1999mmdd value instead of the 99mmdd that I was using, and it
 DOES NOT WORK - bombs completely! The study uses DateToJulian. I've not
 tried (yet) to track down the problem, but there *does* seem to be a
 problem. 
 
 Perhaps "TS" is Y2k compliant (dates in data), but Easy Language is not?? 
 That would SURE be a problem! But Omega could still claim "TS" is Y2k
 compliant -- after all, EL *is* a different piece of software :-). 
 
 Any comments? Anyone tried YYYY dates in EL date functions?
 
 Larry
 
  >>
==================================