valid/datetime/no-seconds fails when the decoder does not add now-optional seconds in the JSON output

[dmbaturin]

This is what happens if the decoder outputs values without seconds as they were in the TOML file:

FAIL valid/datetime/no-seconds
     Malformed output from your encoder: key "without-seconds-1" is not a datetime: "13:37"

     input sent to parser-cmd (PID 186360):
        1 │ # Seconds are optional in date-time and time.
        2 │ without-seconds-1 = 13:37
        3 │ without-seconds-2 = 1979-05-27 07:32Z
        4 │ without-seconds-3 = 1979-05-27 07:32-07:00
        5 │ without-seconds-4 = 1979-05-27T07:32

     output from parser-cmd (PID 186360) (stdout):
        1 │ {
        2 │   "without-seconds-1": {"type": "time-local", "value": "13:37"},
        3 │   "without-seconds-2": {"type": "datetime", "value": "1979-05-27 07:32Z"},
        4 │   "without-seconds-3": {"type": "datetime", "value": "1979-05-27 07:32-07:00"},
        5 │   "without-seconds-4": {"type": "datetime-local", "value": "1979-05-27T07:32"}
        6 │ }

     want:
        1 │ {
        2 │     "without-seconds-1": {"type": "time-local", "value": "13:37:00"},
        3 │     "without-seconds-2": {"type": "datetime", "value": "1979-05-27T07:32:00Z"},
        4 │     "without-seconds-3": {"type": "datetime", "value": "1979-05-27T07:32:00-07:00"},
        5 │     "without-seconds-4": {"type": "datetime-local", "value": "1979-05-27T07:32:00"}
        6 │ }

If seconds are optional in the TOML representation, should they be optional in the JSON output for the test runner as well?

[arp242]

toml-test only tests semantic equality, not the format in which it was given. Quite a few implementations don't really track if the seconds were given or not because there is no need to and just assume :00. Requiring every TOML parser to track this just for toml-test would not be very helpful (and often not easy; how do you do this in something like Python's datetime.datetime, or Go's time.Time?)

I guess toml-test could accept it, but almost no one is going to have this problem, and keeping things straight-forward is probably best instead of accepting multiple formats.

So just encode it as 13:37:00 in your JSON, basically.