See http://www.pickwiki.com/cgi-bin/wiki.pl?Date_Conversion_With_ICONV for a
discussion of how ICONV deals with wholly numeric external dates.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Sounds like you have hit the problem where, depending on the UDT.OPTIONS
82 value, the system will evaluate to external format first. If you
change the UDT.OPTIONS 82 value then you should find it will work.
The manual states that this should only happen with dates starting 10,
11 or 12... But
It's simply because 14001 through 14365 will resolve in the D2
conversion. That is a bad programming practice to use a DICT item with
D2 and force internal format data for the compare. Just to be clear,
this is not a problem with the system as all, this is just someone using
the system
Hmm
14001 through 14365 are a valid julian dates (14001 = 1 Jan 2014)
So it is reading these as external dates in your selection. 14000 is not a
valid julian date, so it is reading it as internal.
Just why are you trying to force selection using an internal date when you
have a date conversion?
[EMAIL PROTECTED] wrote:
We just ran into a strange issue where LIST/SELECT cannot resolve an
internal date - and it's for a block of one full year.
SNIP
SELECT TESTFILE WITH DATE 14366
Bad data 14366 for conversion D2/. Unconverted data used for
selection.
SNIP
I can't replicate your
Snyder [mailto:[EMAIL PROTECTED]
Sent: 09 June 2006 16:03
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UniVerse Internal Date Blackout
[EMAIL PROTECTED] wrote on 06/09/2006 10:16:08 AM:
SELECT TESTFILE WITH DATE 14000
Bad data 14000 for conversion D2/. Unconverted data used
Pointing out the obvious was very helpful, thanks. Gives me great
confidence in dealing with IBM on odd issues such as this.
We're dealing with report code written by a vendor (who knows what bizarre
reason they had), and found the issue when the report wasn't returning
expected results. We
Thanks. Same thing happens with 13001 - 13365, etc. Not sure why our
vendor wrote it that way, but we added the internal DICT items to handle
it. Even though it's bad practice (we scratched our heads too when we
uncovered it this morning), we were still puzzled why it does actually work
for
[EMAIL PROTECTED] wrote on 06/09/2006 11:40:36 AM:
Pointing out the obvious was very helpful, thanks. Gives me great
confidence in dealing with IBM on odd issues such as this.
We're dealing with report code written by a vendor (who knows what
bizarre
reason they had), and found the issue
@listserver.u2ug.org
Subject: Re: [U2] UniVerse Internal Date Blackout
Pointing out the obvious was very helpful, thanks. Gives me great
confidence in dealing with IBM on odd issues such as this.
We're dealing with report code written by a vendor (who knows what
bizarre
reason they had), and found the issue when
10 matches
Mail list logo
