Millisecond decoder tests pass with second precision output

[Benjamin Yeung]

I was working on a decoder that had not yet implemented fractional second precision. I ran an in-progress version that parsed the fractional second input but still generated output with second precision, and was surprised to discover that it passed all of the toml-test v1.3 datetime tests. Here's sample verbose output:

PASS valid/datetime/milliseconds

     input sent to parser-cmd:
       utc1  = 1987-07-05T17:45:56.1234Z
       utc2  = 1987-07-05T17:45:56.6Z
       wita1 = 1987-07-05T17:45:56.1234+08:00
       wita2 = 1987-07-05T17:45:56.6+08:00

     output from parser-cmd (stdout):
       {"utc1":  {"type":"datetime","value":"1987-07-05T17:45:56Z"},
        "utc2":  {"type":"datetime","value":"1987-07-05T17:45:56Z"},
        "wita1": {"type":"datetime","value":"1987-07-05T17:45:56+08:00"},
        "wita2": {"type":"datetime","value":"1987-07-05T17:45:56+08:00"}}

     want:
       {
         "utc1": {
           "type": "datetime",
           "value": "1987-07-05T17:45:56.1234Z"
         },
         "utc2": {
           "type": "datetime",
           "value": "1987-07-05T17:45:56.6000Z"
         },
         "wita1": {
           "type": "datetime",
           "value": "1987-07-05T17:45:56.1234+08:00"
         },
         "wita2": {
           "type": "datetime",
           "value": "1987-07-05T17:45:56.6000+08:00"
         }
       }

It also passes valid/datetime/local-time and valid/datetime/local, with the same issue. Is this expected behavior for decoder tests or should this be corrected?

[Martin Tournoij]

It's a limitation.

When parsing the time the subseconds are treated as optional by the Go time parser; what it should do in cmpAsDateTimes() is first parse want to check how many subseconds there are, and then use the appropriate layout.