$dateFromString cannot handle timezone 'Z'

[ErisDS]

I discovered an issue where supplying dateFromString with a valid date ending in Z results in undefined.

I'm doing something like:

const criteria = { $expr: {
    $gte:
        [
            {
                $dateFromString:
                {
                    dateString: '$created_at',
                    format: '%Y-%m-%dT%H:%M:%S.%LZ'
                }
            },
            {
                $dateSubtract:
                {
                    startDate: '$$NOW',
                    unit: 'week',
                    amount: 1
                }
            }
        ]
}};

useOperators(OperatorType.EXPRESSION, {$dateSubtract, $dateFromString});
const query = new Query(criteria);

query.test({created_at: '2022-02-24T14:13:00'})
// dateFromString returns 2022-02-24T14:13:00.000Z 


query.test({created_at: '2022-02-24T14:13:00Z'})
// dateFromString returns undefined

I'm expecting this to work due to a couple of things mentioned in the mongo docs

If unspecified, $dateFromString uses "%Y-%m-%dT%H:%M:%S.%LZ" as the default format.

If the dateString argument is formatted like '2017-02-08T12:10:40.787Z', in which the 'Z' at the end indicates Zulu time (UTC time zone), you cannot specify the timezone argument.

These indicate that the Z format for indicating UTC is supported, as it is the default output and there is special behaviour for it.

I have done a bit of debugging and discovered that it's failing on the regex.exec clause here:

mingo/src/operators/expression/date/dateFromString.ts

Line 95 in 667fc61

!new RegExp("^" + expectedPattern + "$").exec(args.dateString)

But I'm not entirely sure what that clause is meant to do.

[kofrasa]

Thanks for adding the test case. Looking at the code it seems we are just ignoring a potential Z at the end of the date string value.

You can fix this by changing the referenced line to include an optional Z.

 !new RegExp("^" + expectedPattern + "Z?$").exec(args.dateString) 

That would pass inputs like 2013-09-12Z which is valid from my tests on https://mongoplayground.net/. It seems every alphabet adds some offset to the time value according to military timezones so even 2013-09-12A is valid and should ideally be handled for 100% compatibility.

Supporting that though, would require more work so I am happy for us to address the dominant use case for now as suggested above.

Happy to accept a PR.