# Strange Behavior on dates subtraction **URL:** \ **Category:** Forum\ **Tags:** Adabas-Natural, Natural, Natural-on-Mainframes\ **Created:** [June 29, 2021, 2:40pm UTC](https://techcommunity.softwareag.com/t/strange-behavior-on-dates-subtraction/242463 "2021-06-29T14:40:21Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Marcelo\_Oliveira1](https://avatars.discourse-cdn.com/v4/letter/m/8491ac/32.png) [@Marcelo\_Oliveira1](https://techcommunity.softwareag.com/u/Marcelo_Oliveira1)\ **Post date:** [June 29, 2021, 2:40pm UTC](https://techcommunity.softwareag.com/t/strange-behavior-on-dates-subtraction/242463/1 "2021-06-29T14:40:21Z")
Hello there again. Do you guys could shed a light on this issue I’m facing? I know how to solve, but I can’t understand why it is happening. this is part of the program. ```auto LOCAL 1 #DAYS (N5) 1 #MAX (N5) 1 #far (d) END-DEFINE #DT := D'2021-06-28' READ MULTI-FETCH OF 10 PAR WITH CD-ST-PARC EQ ' ' THRU ' ' #DAYS := #DT - DT-VALID /* (d) this is the valid date on the billings. IF #DAYS > #MAX #MAX := #DAYS #FAR := DT-VALID END-IF IF #DAYS GT 9999 WRITE 'above 9999 =' #DAYS END-IF END-READ WRITE '=' #MAX '=' #FAR (EM=YYYYMMDD) END ``` this is the result: 8210 19990105 so far, ok. The issue is that the version that is in production has #days defined as (n4). And I’m receiving 1320 (numeric value truncated) You see that the oldest value for date I’ve got here is 1999-01-05. It doesn’t go over 9999 days. The if block is never used… I know I could just go and increase the N4 to N5 in production and here we go, but I need to understand why 8210 doesn’t fit in a N4 in this case. As always, thanks in advance, Marcelo. ---
**Author:** ![Ralph\_Zbrog](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/ralph_zbrog/32/78_2.png) [@Ralph\_Zbrog](https://techcommunity.softwareag.com/u/Ralph_Zbrog)\ **Post date:** [June 29, 2021, 3:31pm UTC](https://techcommunity.softwareag.com/t/strange-behavior-on-dates-subtraction/242463/2 "2021-06-29T15:31:06Z")
First, I think you meant error number 1305. 1320 refers to the VAL function. Second, check your file for null date values. #DT - 0 = 738333, a 6-digit result. ---
**Author:** ![Lukas\_Hundemer](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/lukas_hundemer/32/113_2.png) [@Lukas\_Hundemer](https://techcommunity.softwareag.com/u/Lukas_Hundemer)\ **Post date:** [June 29, 2021, 3:43pm UTC](https://techcommunity.softwareag.com/t/strange-behavior-on-dates-subtraction/242463/3 "2021-06-29T15:43:39Z")
Maybe an intermediate result is too big. ---
**Author:** ![Marcelo\_Oliveira1](https://avatars.discourse-cdn.com/v4/letter/m/8491ac/32.png) [@Marcelo\_Oliveira1](https://techcommunity.softwareag.com/u/Marcelo_Oliveira1)\ **Post date:** [June 29, 2021, 4:41pm UTC](https://techcommunity.softwareag.com/t/strange-behavior-on-dates-subtraction/242463/4 "2021-06-29T16:41:30Z")
> [@Ralph\_Zbrog](#): > > First, I think you meant error number 1305. 1320 refers to the VAL function. > > Second, check your file for null date values. #DT - 0 = 738333, a 6-digit result Hi Ralph. Thank you as always. First yes, you are right. I confused the errors, it’s a 1305. About the null, as you can see, when I define it as a N5, there is no problem and there should be if it was the case of returning a 6-digit to a N5. Also, if there was a null value, I believe the if block would be used and would display the value, because it would be bigger than 9999 days, but it doesn’t happen. That’s why I’m confused. [edit] I found out the issue. The database is very large and it makes difficult to find because the date is not a descriptor, but I managed to put an ‘on error’, forcing it to show me what was coming in. after 1h running, I found out that one of the valid-dt is set on 2122-01-22 which is another issue, but clearly explains how the value became so big. the if block is testing for GT 9999, but not LT -9999. initially i was afraid of something that could be hidden and using space of the numbers, because i’m not calculating over N dates, but D dates. ---
**Author:** ![Ralph\_Zbrog](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/ralph_zbrog/32/78_2.png) [@Ralph\_Zbrog](https://techcommunity.softwareag.com/u/Ralph_Zbrog)\ **Post date:** [June 29, 2021, 5:07pm UTC](https://techcommunity.softwareag.com/t/strange-behavior-on-dates-subtraction/242463/5 "2021-06-29T17:07:35Z")
```auto #DAYS := #DT - DT-VALID ``` This will be the statement failing on the NAT1305, so your IF statement won’t be executed. Unless you can guarantee valid dates, #DAYS must be defined as N6 or P6. If your Natural parameters have set MAXYEAR to 9999, then #DAYS should be defined as N7 or P7. ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [September 27, 2021, 5:08pm UTC](https://techcommunity.softwareag.com/t/strange-behavior-on-dates-subtraction/242463/6 "2021-09-27T17:08:12Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.