Entry @d1 Bug when 4 Digit Year is entered it flips Month and Day

An ENTRY(@d1) is format MM/DD/YY with a 2 digit year. Entering dates in Clarion is very flexible and converts to the Entry Picture e.g. you can omit the slashes.

I found a bug that if a 4 digit Year is entered into a ENTRY(@d1) the RTL will Flip the Month and Day (when Day is <= 12).

So as shown entering July 4th as 07042024 or 7/4/2024 it will convert to 2 digit Year then flip MM/DD and set the date to 04/07/24 i.e. April 7th. This is confirmed by the STRING(@d4) out to the right.

Recording Entry @d1 Bug

This does not happen for Entry(@d5) = DD/MM/YY . I made the above Animated GIF screen capture using the GifCap website.


Test Code. I’ve checked C10, 11.0 and 11.1.

    PROGRAM
    MAP
D1BugTest  PROCEDURE()
    END
    CODE
    D1BugTest()
!----------------------------
D1BugTest   PROCEDURE
d1  LONG
d2  LONG
d5  LONG
d6  LONG

Window WINDOW('Entry @d1 Bug YYYY'),AT(,,282,121),GRAY,IMM,AUTO,SYSTEM,FONT('Segoe UI',9),RESIZE
        STRING('Enter @d1 Date as 07042024 or 7/4/2024 (4 digit year)    i.e. July 4th'),AT(7,2), |
                USE(?BugFyi_1)
        STRING('Press Tab and see @d1 flips Month & Day so = 4/7/24   i.e. April 7th'),AT(7,12), |
                USE(?BugFyi_2)
        PROMPT('Entry @d1 M-D-YY'),AT(7,27),USE(?Prompt:D1)
        ENTRY(@d01b),AT(87,27,67,11),USE(d1)
        STRING(@d04b),AT(168,27),USE(d1,, ?d1:d4)
        PROMPT('Entry @d2 M-D-YYYY'),AT(7,42),USE(?Prompt:D2)
        ENTRY(@d02b),AT(87,42,67,11),USE(d2)
        STRING(@d04b),AT(168,42),USE(d2,, ?d2:d4)
        PROMPT('Entry @d5 DD-M-YY'),AT(7,65),USE(?Prompt:D5)
        ENTRY(@d05b),AT(87,65,67,11),USE(d5)
        STRING(@d04b),AT(168,65),USE(d5,, ?d5:d4)
        PROMPT('Entry @d6 DD-M-YYYY'),AT(7,80),USE(?Prompt:D6)
        ENTRY(@d06b),AT(87,80,67,11),USE(d6)
        STRING(@d04b),AT(168,80),USE(d6,, ?d6:d4)
    END

    CODE
    OPEN(WINDOW)
    0{PROP:text}=clip(0{PROP:text}) &' - Library ' & system{PROP:LibVersion,2} &'.'& system{PROP:LibVersion,3}
    ACCEPT
    END

d1_EntryBugYYYY_Proj.zip (1.3 KB)

I think the old accounting software I work on used ENTRY(@d1) to simply have less characters shown and take less space, the century was seen as needless clutter.

The obvious workaround is to change ENTRY’s that use @D1 to @D2. The user can still enter 2 digit years and it converts.

Any other ideas to trap Intellidate Entry of YYYY into an @D1 Entry? There is no Event Rejected.

Ignore all this with @D17 working. It has a 4 digit year so of course it works.

I just tried ENTRY(@d17) the Windows Short date and that does Not have the bug. On my system that is MM/DD/YY. So that would keep the same look. ~~

I have never used @D17 or @D18 because I always work with in the USA. Seems possible that could be specified with a 4 digit YYYY which would not fit in the current Entry Width.

On GitHub I have a Date Time Number. It figures out @D Pictures by using a value like 10/11/2012 that has unique values for M, D and Y.


Attached v2 of bug test with D17 … to repeat it has a YYYY so it works…

        PROMPT('Entry @d17 Win Short'),AT(7,100),USE(?Prompt:D17)
        ENTRY(@d017b),AT(87,100,67,11),USE(d17)
        STRING(@d018b),AT(168,100),USE(d17,, ?d17:d4)

d1_EntryBugYYYY_Proj_v2_d17.zip (1.4 KB)

1 Like

I just use @d17b for everything and am slowly planning ahead for the 2038 millenium bug pt2.

Fortunately like millenium bug 1, millenium bug 2 doesnt apply to Clarion.

Clarion isnt affected but the databases are if using a Long to store the Unix date time which starts from their 1970 epoch.

Clarion times out in some places in 2099 with Star Dates, Date Calcs and Unix dates.