Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Millisecond decoder tests pass with second precision output #136

Open
bzyeung opened this issue Jun 26, 2023 · 1 comment
Open

Millisecond decoder tests pass with second precision output #136

bzyeung opened this issue Jun 26, 2023 · 1 comment

Comments

@bzyeung
Copy link

bzyeung commented Jun 26, 2023

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?

@arp242
Copy link
Collaborator

arp242 commented Jun 28, 2023

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.

@arp242 arp242 closed this as completed in 31dcd40 Sep 30, 2023
@arp242 arp242 reopened this Oct 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants