Encoder tests expect submillisecond precision

[cyyynthia]

I have a bunch of tests fail for my toml encoder due to tests expecting my encoder to output time with submillisecond precision.

FAIL valid/spec/local-date-time-0
     Values for key "ldt2" differ:
       Expected:     1979-05-27 00:32:00.999999 +0200 datetime-local (time.Time)
       Your encoder: 1979-05-27 00:32:00.999 +0200 datetime-local (time.Time)

FAIL valid/spec/local-time-0
     Values for key "lt2" differ:
       Expected:     0000-01-01 00:32:00.999999 +0200 time-local (time.Time)
       Your encoder: 0000-01-01 00:32:00.999 +0200 time-local (time.Time)

FAIL valid/spec/offset-date-time-0
     Values for key "odt3" differ:
       Expected:     1979-05-27 00:32:00.999999 -0700 -0700 (time.Time)
       Your encoder: 1979-05-27 00:32:00.999 -0700 -0700 (time.Time)

[arp242]

Not entirely sure what the best solution is; these tests are examples from the spec, and I'd like to keep all of them.

I'm not sure if it's worth adding a flag for this; not many implementations support only ms precision.

Why not support ns precision in your JS parser? Not a JS expert, but doesn't the Date type support that?

[cyyynthia]

JS' Date object encapsulate an integral number that represents milliseconds since the midnight at the beginning of January 1, 1970, UTC (the epoch). (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date). I could use a custom object that adds submillisecond precision, but that'd be a custom extension to the Date object.

I understand these are examples from the spec, but the spec also mentions quite clearly only millisecond precision is required, and that additional precision is implementation-specific; as such I'd assume a parser that only outputs millisecond-precision would pass tests, at least the "default ones". Maybe an "extended spec support" flag could be added that'd test for submillisecond precision, but they should be opt-in IMHO.

[arp242]

Right, thanks.

I'd prefer to have the common case be the default, which is support for 64bit ints and datetime ns precision. AFAIK JavaScript is the only mainstream language that doesn't support that well natively.

Not sure what the best approach is; also need to consider that many people don't use the toml-test binary but use toml-test -copy to copy the test files and then implement their own test runner. Need to think about it, and see what works.