$toMillis() Incorrectly parses the H (hour) and m (minute) field length in a non-character deliniated timestamp string, ignoring width modifiers

[Dowster64]

The $toMillis() function does not follow the picture string for XPath and XQuery for at least the H value (and the m), either by the presentation modifier or the width modifier when a character separator (e.g :) is not present. Note I have removed all other character separators (it does have knock on effects though) For example, given:

{"payload":"20250703T231120Z"}

When using this query in the JSONata Exerciser and NodeRED:

[	    payload,	   $toMillis(payload,"[Y1111][M11][D11]T[H1,2-2][m1,2-2][s1,2-2]Z")~>$fromMillis()]

Produces this result:

[
  "20250703T231120Z",
  "2025-10-07T07:02:00.000Z"
]

The corresponding date represents 2311 hours (96 days and 7 hours) added to the base date of 2025-07-03 (00 minutes - midnight) with the original 20 seconds interpreted as 2 minutes.

If this string is provided and the picture modified as shown, you get the following:

{"payload":"20250703T2311:20Z"}
[	    payload,	   $toMillis(payload,"[Y1111][M11][D11]T[H1,2-2][m1,2-2]:[s1,2-2]Z")~>$fromMillis()]
[
  "20250703T2311:20Z",
  "2025-07-12T15:01:20.000Z"
]

Which treats the hours as 231, which is 9.625 days or 9 and 15/24 of a day and the last figures of 1:20 as hours and minutes.

Apologies for the messy edits - the minutes are a problem too:

{"payload":"20250703T23:1120Z"}
[	    payload,	   $toMillis(payload,"[Y1111][M11][D11]T[H1,2-2]:[m1,2-2][s1,2-2]Z")~>$fromMillis()]

[
  "20250703T23:1120Z",
  "2025-07-04T00:52:00.000Z"
]

AFAIK I am using the presentation and width modifiers as per the XPath link in the documentation:
https://www.w3.org/TR/xpath-functions-31/#func-format-dateTime

Even with the weird example that 01,11, 99 allows results of 3 characters wide:
"
The corresponding output format is a decimal number, using this digit family, with at least as many digits as there are mandatory-digit-signs in the format token. Thus, a format token 1 generates the sequence 0 1 2 ... 10 11 12 ..., and a format token 01 (or equivalently, 00 or 99) generates the sequence 00 01 02 ... 09 10 11 12 ... 99 100 101
"
https://www.w3.org/TR/xpath-functions-31/#func-format-integer

Hence the use of the width modifier to try and force 2 characters min and max (0 as min isn't allowed) Missing second fractions (milliseconds) does not seem to affect the result either.

[tiebingzhang]

looks like this is now fixed in version 2.1.0.

const jsonata = require('jsonata');

const data = {};
const expression = jsonata("$fromMillis($toMillis('1430', '[H01][m01]'), '[H01]:[m01]')");
expression.evaluate(data).then(result => { console.log(result); });


payload= {"payload":"20250703T231120Z"};
exp2= jsonata('[payload,$toMillis(payload,"[Y1111][M11][D11]T[H1,2-2][m1,2-2][s1,2-2]Z")~>$fromMillis()]');
exp2.evaluate(payload).then(result => { console.log(result); });


payload= {"payload":"20250703T2311:20Z"}
exp2= jsonata('[	    payload,	   $toMillis(payload,"[Y1111][M11][D11]T[H1,2-2][m1,2-2]:[s1,2-2]Z")~>$fromMillis()]');
exp2.evaluate(payload).then(result => { console.log(result); });

payload= {"payload":"20250703T23:1120Z"}
exp2= jsonata('[	    payload,	   $toMillis(payload,"[Y1111][M11][D11]T[H1,2-2]:[m1,2-2][s1,2-2]Z")~>$fromMillis()]');
exp2.evaluate(payload).then(result => { console.log(result); });

output

14:30
[ '20250703T231120Z', '2025-07-03T23:11:20.000Z' ]
[ '20250703T2311:20Z', '2025-07-03T23:11:20.000Z' ]
[ '20250703T23:1120Z', '2025-07-03T23:11:20.000Z' ]

@andrew-coleman @Dowster64 this can be closed?