Edit mask and time fields

, ,
1

Hi,

Does anyone know why I get the result ‘02’ with the following code :o ?

0020 reset #date-t(t) #date-dd(a2)
0030 move edited #date-t(em=dd) to #date-dd
0040 display #date-dd
0050 end

Incidentally, if I specify em=yyyy instead then ‘0000’ is the result
and if I specify em=mm then ‘01’ is the result.

This code was run using Natural V2.2.3 and Adabas V3.1

2

What do you expect to see when you reset a time field to a null value?

If you display the date field with an edit mask, then you will see that the “02” value for DD is to be expected.

RESET #DATE-T(T) #DATE-DD(A2) 
MOVE EDITED #DATE-T(EM=DD) TO #DATE-DD 
DISPLAY #DATE-DD #DATE-T (EM=MM/DD/YYYY^HH:II:SS.T) 
END
#DATE-DD        #DATE-T 
-------- --------------------- 
 
02       01/02/0000 00:00:00.0

RESET sets a date field to January 2, 0000.

3

That’s correct. I know that the internal format are tens of seconds since January 2, 0000. But I wonder why the time has such a strange zero point…

And Natural’s documentation doesn’t say anything about it…
http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat424mf/sm/defineda_vari.htm#Default_Initial_Values_defineda_vari

4

What is even stranger is shown below:

RESET #DATE-T(T) #DATE-DD(A2)
REDEFINE #DATE-T (#DD (P13))
MOVE EDITED #DATE-T(EM=DD) TO #DATE-DD
DISPLAY #DATE-DD #DD (EM=H(13))
END
Page 1 08-05-19 07:58:58

#DATE-DD #DD

02 0000000000000C

The RESET does indeed set #DATE-T to Binary zeroes (C of course is just the sign).

It is the “conversion” routine that converts a date/time variable to an alpha string for output (or a MOVE) that “creates” the strange date of January 2 0000

steve

5

You don’t see this strange behavior with D-format fields. And with Time fields, you can use ZP=F to avoid the display of the bogus date.

RESET #D (D) #T (T)
DISPLAY #D                               #D (EM=DD)
        #T (EM=MM/DD/YY^HH:II:SS.T)      #T (EM=DD)
        #T (EM=MM/DD/YY^HH:II:SS.T ZP=F) #T (EM=DD ZP=F)
.
   #D    #D         #T          #T         #T          #T
-------- -- ------------------- -- ------------------- --

            01/02/00 00:00:00.0 02
6

Hi Ralph,

To answer your question:

7

To be honest: I don’t think so. Your program proves, that the zero point is January 2 0000. It doesn’t prove that the conversion routine is wrong.

First of all: Date and Time field got the same zero point internally. Try this:

define data local
1 #d (D)
1 redefine #d
  2 #p7 (p7)
1 #t (T)
1 redefine #t
  2 #p13 (P13)
1 #i4 (I4)
end-define
#d := D'1582-01-01' /* earliest date possible
#t :=  D'1582-01-01'
write '=' #d (EM=YYYY-MM-DD) #p7
write '=' #t (EM=YYYY-MM-DD^HH:II:SS.T) #p13
#i4 := #p13 / 10 / 60 / 60 / 24
write '#t --> #d' #i4
end

If we take the julian calendar (which was in use before 1582 A.D.) we got to more than 577813 days (1582 * 365 + 1580 / 4 = 577825). So it has to be the gregorian calendar with the special leap year rule. Let’s try to calculate back the internal date value of Natural to year 0:

define data local
1 #i4  (I4)
1 #year(I2)
1 #rem (N4)
1 #n4  (N4)
1 #leap (L)
end-define
*
#i4 := 577813 /* i.e. 1582-01-01
*
for #year = 1581 to 0 step -1
  #i4 := #i4 - 365
*
* find out gregorian leap year
*
  reset #leap
  divide 400 into #year giving #n4 remainder #rem
  if #rem = 0
    #leap := true
  else
    divide 100 into #year giving #n4 remainder #rem
    if #rem = 0
      ignore
    else
      divide 4 into #year giving #n4 remainder #rem
      if #rem = 0
        #leap := true
      end-if
    end-if
  end-if
  if #leap
    #i4 := #i4 - 1
  end-if
  write 'January 1' #year '-->' #i4 #leap
end-for
*
end

My output is:

January 1   1581 -->      577448
January 1   1580 -->      577082 X
January 1   1579 -->      576717
January 1   1578 -->      576352
January 1   1577 -->      575987
January 1   1576 -->      575621 X
[...]
January 1      5 -->        1826
January 1      4 -->        1460 X
January 1      3 -->        1095
January 1      2 -->         730
January 1      1 -->         365
January 1      0 -->          -1 X

So: Zero point is January 2 0000

Questions:

  1. Why is it the January 2 and not January 1?
  2. Why is it year 0000? Year 0000 doesn’t exist in the julian and gregorian calendar.

Possible explanation: Year 0000 is 1 B.C. in reality which is not a leap year. Then the zero point would be January 1st 0001 B.C.

8

"It doesn’t prove that the conversion routine is wrong. "

I never said the conversion routine was wrong. I was merely pointing out that the conversion routine starts with a string of zeroes, which is what one would expect from a RESET, and produces something I find a bit strange, namely January 2, 0000.

Thanks Ralph for the tip on ZP; had never tried that. However, to my way of thinking, I should not have to turn ZP off to get rid of the “strange date”.

Of course, I cannot imagine someone trying to write out a RESET date variable in a production program. That leaves development. As a developer, I think I would probably want to see something like 00-00-0000 so I would know, if I were trying to follow some logic, that I had just RESET the variable, and had not modified it since then.

steve