Hi all,
Prior to BR 4.18, using the DAYS function on a string would return an error.
Now it does not. I have no problem with this because it allows us to do date validate on strings. It's a good thing (in the words of Martha Stewart).
days("122509","mdcy") returns 40171 This is correct.
But if you run days on a blank string, it doesn't return 0 as I would assume. It returns 40086 (or October 1, 2009) Why is that? I have programs where dates that should be blank are being initialized to 10/01/09 instead. This can't be right, can it? I'm fixing this by coding around it, but it seems like a bug to me and now I'm in the process of tracking down every place where I depended upon the result being 0.
If it's not a bug, can someone explain it to me? This happens in 4.18 and 4.2 as far as I can tell. My systems written in 4.03 did not do this, but I don't think you could do any date functions on strings back then.
-- Susan
Date/Days functions
Moderators: Susan Smith, admin, Gabriel
-
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
-
- Posts: 25
- Joined: Thu Jun 11, 2009 9:04 am
- Location: Edmonton
- Contact:
-
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
If this is how it is SUPPOSED to work, I'd love to hear the reasoning behind it, if anyone knows. It certainly created some unexpected (and WRONG) results for my programs which I didn't catch for a long time. I ran into this "days" behavior a few weeks ago writing some NEW programs in 4.2 and just assumed it was a 4.2 thing. So I just changed some routines and am now working around it.
But now I look back on another system that I had upgraded from 4.03 to 4.18 some time ago without doing anything to these date routines, and now the client has bad data in their files that they can't account for. One program processes text files from an outside source and if the date is bad, we discard the record and don't import it. I was using the results of "days" to determine the validity of the data. The bad records got through and were written to data files because my program saw the dates as legitimate...for several YEARS now. Unfortunately, the auditors caught it for me. Ouch.
-- Susan
But now I look back on another system that I had upgraded from 4.03 to 4.18 some time ago without doing anything to these date routines, and now the client has bad data in their files that they can't account for. One program processes text files from an outside source and if the date is bad, we discard the record and don't import it. I was using the results of "days" to determine the validity of the data. The bad records got through and were written to data files because my program saw the dates as legitimate...for several YEARS now. Unfortunately, the auditors caught it for me. Ouch.
-- Susan