Is there some reason for the inconsistency in the way DS handles invalid dates?
For Example, a day value that exceeds the normal range for that month returns null, but if it happens to be February 29th in a non-leap year, it returns the first of the next month.
This means there is no way to capture invalid dates by looking for null output. Is there a way to get around this?
Thanks.
Date Cleansing
Moderators: chulett, rschirm, roy
Returns null from what? How are you doing your date handling / checking? Read the online help for the Status() function, it comes in very handy for date handling inside a routine and the example there is specific to date validation, from what I recall.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
The trick is to ICONV a date, then OCONV the date and verify that the same month comes back.
For fun, try 2-28, 2-29, 2-30, and 2-31. See what happens. Fun with dates!!!
For fun, try 2-28, 2-29, 2-30, and 2-31. See what happens. Fun with dates!!!
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Gsherry1,
The OCONV/ICONV functions all return a status code. When a date could be correct and a rule can be followed, the conversion is done and a warning STATUS is returned {which is of course ignored in derivations}; while an invalid date isn't converted and an error STATUS is set {once again, unused and ignored in mere derivations?}.
In order to change this behaviour you need to put the conversion into a routine and handle the potential warnings and errors yourself.
So the date conversions are not really inconsistent, we just don't normally use the full functionality.
The OCONV/ICONV functions all return a status code. When a date could be correct and a rule can be followed, the conversion is done and a warning STATUS is returned {which is of course ignored in derivations}; while an invalid date isn't converted and an error STATUS is set {once again, unused and ignored in mere derivations?}.
In order to change this behaviour you need to put the conversion into a routine and handle the potential warnings and errors yourself.
So the date conversions are not really inconsistent, we just don't normally use the full functionality.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>