Highlighted

Acrobat Fillable Date Fields no longer autoformat yyyy-mm-dd

New Here ,
Oct 03, 2020

Copy link to clipboard

Copied

Our organization is international.  The forms I work with require ISO date format yyyy-mm-dd.

 

PREVIOUSLY, when filling the forms with Adobe Acrobat or with Acrobat Reader,the forms would automatically convert dates enetered in other formats.  For example:

     Keying in "2002-08-12" would be accepted and displayed as: 2002-08-12.

     Keying in "August 12, 2002" would be accepted and would immediately display: 2002-08-12.

     Similarly a date entered as "8/12/2002" would be converted and displayed as : 2002-08-12.

     Following entry, a return to the date field would display the converted format:  2002-08-12.

These forms have all been created exclusively with Adobe Acrobat DC.

When filling thee forms with other application software (e.g. FOXIT Reader or EDGE browser, new version) the desired entry behavior (described above) is observed.

 

RECENTLY, the Abobe applications seem to have changed behavior when entering dates on our forms.

     Keying in "2002-08-12" (the specified format) still works and displays:  2002-08-12.

     Keying in "August 8, 2012" is rejected with an error message:

               Warning: Javacript Window -

                Invalid date/time: pleae ensure that the date/time exists. Field [ DateOfBirth ] should match

                format yyyy-mm-dd

     Keying in "8/12/2012" is rejected with the same error mesage:

(Interestingly, the forms still continue to work okay with Foxit Reader and EDGE browser, i.e. valid dates in other formats are automatically converted to yyyy-mm-dd format and accepted.)

 

If the date field format is changed to something else such as mm/dd/yyyy, I observe the following:

     Keying in "8/12/2002" is accepted and displays: "08/12/2002"

     Keying in  "12 Aug 2002" is accepted and displays: "08/12/2002"

     Keying in  "August 12, 2002" is accepted and displays: "08/12/2002"

           Returning to the date field after entry causes the originally entered text to reappear,

           e.g. "8/12/2002", "12 Aug 2002" or "August 12, 2002" but the converted date "08/12/2002"

           replaces this, again, when leaving the field.  

            (That is, Acrobat is retaining both forms of the data:

                  the originally entered date; and the reformatted date.)

     Keying in 2002-08-12 is rejected and displays:

               Warning: JavaScript Window -

               Invalid date/time: please ensure that the date/time exists. Field [ test date ] should match

               formate mm/dd/yyyy

I don't mind the fact that the original entry is also preserved when converted to a specified date entry format.  I can see both "pros and cons" to this behavior, which seems to have changed in the last month or so.  But what does this fail for yyyy-mm-dd?

 

I am perplexed by the failure of Adobe to fully support yyyy-mm-dd format for date entry on forms.  This is the date format specified by ISO 8601.   (I have also noted that Adobe Sign fails to recognize yyyy-mm-dd as a standard date format.  This means yyyy-mm-dd must be entered as a "custom" date format in Adobe Sign, even though the date originated from an Adobe Acrobat PDF form field.)

 

How can we get Acrobat to fully support yyyy-mm-dd date format with automatic conversion of entries made using other valid date formats?    (Or am I missing something.  Perhaps a workaround?)

TOPICS
PDF forms

Views

91

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Acrobat Fillable Date Fields no longer autoformat yyyy-mm-dd

New Here ,
Oct 03, 2020

Copy link to clipboard

Copied

Our organization is international.  The forms I work with require ISO date format yyyy-mm-dd.

 

PREVIOUSLY, when filling the forms with Adobe Acrobat or with Acrobat Reader,the forms would automatically convert dates enetered in other formats.  For example:

     Keying in "2002-08-12" would be accepted and displayed as: 2002-08-12.

     Keying in "August 12, 2002" would be accepted and would immediately display: 2002-08-12.

     Similarly a date entered as "8/12/2002" would be converted and displayed as : 2002-08-12.

     Following entry, a return to the date field would display the converted format:  2002-08-12.

These forms have all been created exclusively with Adobe Acrobat DC.

When filling thee forms with other application software (e.g. FOXIT Reader or EDGE browser, new version) the desired entry behavior (described above) is observed.

 

RECENTLY, the Abobe applications seem to have changed behavior when entering dates on our forms.

     Keying in "2002-08-12" (the specified format) still works and displays:  2002-08-12.

     Keying in "August 8, 2012" is rejected with an error message:

               Warning: Javacript Window -

                Invalid date/time: pleae ensure that the date/time exists. Field [ DateOfBirth ] should match

                format yyyy-mm-dd

     Keying in "8/12/2012" is rejected with the same error mesage:

(Interestingly, the forms still continue to work okay with Foxit Reader and EDGE browser, i.e. valid dates in other formats are automatically converted to yyyy-mm-dd format and accepted.)

 

If the date field format is changed to something else such as mm/dd/yyyy, I observe the following:

     Keying in "8/12/2002" is accepted and displays: "08/12/2002"

     Keying in  "12 Aug 2002" is accepted and displays: "08/12/2002"

     Keying in  "August 12, 2002" is accepted and displays: "08/12/2002"

           Returning to the date field after entry causes the originally entered text to reappear,

           e.g. "8/12/2002", "12 Aug 2002" or "August 12, 2002" but the converted date "08/12/2002"

           replaces this, again, when leaving the field.  

            (That is, Acrobat is retaining both forms of the data:

                  the originally entered date; and the reformatted date.)

     Keying in 2002-08-12 is rejected and displays:

               Warning: JavaScript Window -

               Invalid date/time: please ensure that the date/time exists. Field [ test date ] should match

               formate mm/dd/yyyy

I don't mind the fact that the original entry is also preserved when converted to a specified date entry format.  I can see both "pros and cons" to this behavior, which seems to have changed in the last month or so.  But what does this fail for yyyy-mm-dd?

 

I am perplexed by the failure of Adobe to fully support yyyy-mm-dd format for date entry on forms.  This is the date format specified by ISO 8601.   (I have also noted that Adobe Sign fails to recognize yyyy-mm-dd as a standard date format.  This means yyyy-mm-dd must be entered as a "custom" date format in Adobe Sign, even though the date originated from an Adobe Acrobat PDF form field.)

 

How can we get Acrobat to fully support yyyy-mm-dd date format with automatic conversion of entries made using other valid date formats?    (Or am I missing something.  Perhaps a workaround?)

TOPICS
PDF forms

Views

92

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Oct 03, 2020 0
Most Valuable Participant ,
Oct 03, 2020

Copy link to clipboard

Copied

Are you sure about that? I just tried it with my versions of Reader and Acrobat and "August 12, 2002" is not accepted when the Date format is set to "yyyy-mm-dd". Perhaps you used a custom Format script, but the built-in option in Acrobat/Reader does not allow you to do that.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Oct 03, 2020 0
Most Valuable Participant ,
Oct 03, 2020

Copy link to clipboard

Copied

It does indeed work with "mm/dd/yyyy", though, which is odd... So I did some snopping into the internal code behind this Format script and can explain it, but it's quite technical. The main reason why "12 Aug 2002" is failing for yyyy-mm-dd and doesn't fail for mm/dd/yyyy is that the numbers are matched with the non-month values, in order of appearance, and because in the former pattern the year value comes first, it's matched with "12", which causes an error, while in the latter it's the day value that's matched with "12", and that is fine. If you reverse the first pattern ("dd-mm-yyyy") then it works fine, and if you reverse the second pattern ("yyyy/dd/mm"), it fails too.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Oct 03, 2020 0
New Here ,
Oct 03, 2020

Copy link to clipboard

Copied

Certainly the yyyy-mm-dd is being enforced and impossible dates are excluded.  Correctly formatted entries work fine.  No entry errors are happening.

 

As for incorrect date formats, I would think the presence of one and only one 4-digit numeric (matching yyyy, in either first or last order/position) should parse with priority as a year before determining if there is any ambiguity for the rest of the entry string.  Most non-numeric string components (with a 3-letter month abbreviation or a month fully spelled) along with a 4-digit year wopuld seem to have minimal abiguity if correctly parsed.

 

Of course, one can see that parsing of numeric date formats (even with 4-digit years) may not aways work since there is potential for day vs month ambiguity when attempting to convert inputs with day values of 12 or less.

 

The current behavior is not wrong.   I was expecting non-conforming date formats to automatically convert to "yyyy-mm-dd" just as readily as they to to "mm/dd/yyyy", but the date parsing algorithm is not as powerful as I had thought.

 

Form users will only need to make a few mis-formatted date entries before they learn what is expected, so it would only be a nice "extra touch" to be able to translate an incorrect date format "on-the-fly" (without re-entering).

 

Thank you for looking at the internal code and providing an explanation.  We can live with it.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Oct 03, 2020 0
try67 LATEST
Most Valuable Participant ,
Oct 04, 2020

Copy link to clipboard

Copied

I agree that it would be possible to implement it like that, but it hasn't been. You can always write your own custom Format script and use it instead of the built-in one...

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Oct 04, 2020 0