Unambiguous Dates

The ability handle unambiguous date input has been improved with the addition of numerous “fall through” formats. For date parsing to function, the GlobalCapture fields in question must be of type Date.

This functionality is new in GlobalCapture 3.0. Variants of this behavior were implemented in hotfix form in some prior versions.

Date Parsing

When a date string is set to a property field in GlobalCapture/GlobalAction the engine will attempt to parse the value into a valid UTC formatted date. There are several fall throughs for attempting to output a proper date. If any of the parsing operations are successful, the attempted conversion attempts end. If none are successful, the process will error or the API will prevent process changes from being made. This assumes Data Validation is enabled. The steps to cast to a valid date are:

Attempt to cast the value to an ISO8601 UTC Date: yyyy-MM-ddTHH:mm:ss.fffZ
Use the format mask assigned to the field to attempt a date cast to the specific format.
Check against a list of unambiguous date formats defined in the table below.
Check for a defaultDateFormats.json file, which contains an array of accepted fall through formats in the environment.
1. For the engines to find your defaultDateFormats.json file, the GlobalCapture API and Engine configs must have a basePath key, pointing to the root of the system’s CaptureProcessing folder.
2. A folder named “configuration” exists below the path specified in point a above.
3. defaultDateFormats.json should exist in the configuration folder, and should contain an array of acceptable fall through formats.
  ["G","d","yyyy-MM-dd HH:mm:ss"]

When building workflows where you expect date fall through patterns to help correct/normalize date data, note that you will need to ensure Data Validation is unchecked on any nodes where “invalid” dates are expected and fall through behaviors should be attempted.

It is important to remember when using any regional formats, the region of the Capture API and it's engine's operating systems will be considered as well as system setting for short and long dates. GlobalCapture/GlobalAction will never use a browser's regional location even when validating field data.

Customers should consider using environment specific date fall through (configure the defaultDateFormats.json as per point 4 above) when they are not in control of the inbound documents and the date data being processed across documents is ambiguous. If you are working with documents from multiple sources that might generate ambiguous dates, you may need to consider multiple date fields or multiple workflows for document processing.

Unambiguous Formats

1	yyyyMMddTHHmmsszzz	yyyyMMddTHHZ	yyyy/MM/ddTHH:mm:sszzz
2	yyyyMMddTHHmmsszz	yyyy-MM-ddTHHzzz	yyyy/MM/ddTHH:mm:sszz
3	yyyyMMddTHHmmssZ	yyyy-MM-ddTHHzz	yyyy/MM/ddTHH:mm:ssZ
4	yyyy-MM-ddTHH:mm:ss.fffZ	yyyy-MM-ddTHHZ	yyyy/MM/ddTHH:mmzzz
5	yyyy-MM-ddTHH:mm:sszzz	yyyy.MM.ddTHH:mm:ss.fffZ	yyyy/MM/ddTHH:mmzz
6	yyyy-MM-ddTHH:mm:sszz	yyyy.MM.ddTHH:mm:sszzz	yyyy/MM/ddTHH:mmZ
7	yyyy-MM-ddTHH:mm:ssZ	yyyy.MM.ddTHH:mm:sszz	yyyy/MM/ddTHHzzz
8	yyyyMMddTHHmmzzz	yyyy.MM.ddTHH:mm:ssZ	yyyy/MM/ddTHHzz
9	yyyyMMddTHHmmzz	yyyy.MM.ddTHH:mmzzz	yyyy/MM/ddTHHZ
10	yyyyMMddTHHmmZ	yyyy.MM.ddTHH:mmzz	yyyyMMdd
11	yyyy-MM-ddTHH:mmzzz	yyyy.MM.ddTHH:mmZ	yyyy/MM/dd
12	yyyy-MM-ddTHH:mmzz	yyyy.MM.ddTHHzzz	yyyy-MM-dd
13	yyyy-MM-ddTHH:mmZ	yyyy.MM.ddTHHzz	yyyy.MM.dd
14	yyyyMMddTHHzzz	yyyy.MM.ddTHHZ	o
15	yyyyMMddTHHzz	yyyy/MM/ddTHH:mm:ss.fffZ	u

External Resources

Microsoft date format documentation.