Short dates support

[pelletier]

date4 = 1979-05-27T07:32:00
date5 = 1979-05-27T00:32:00.999999
date6  = 1979-05-27

should all be supported.

[kzys]

I would like to work on this issue. Would it be okay to just extend lexer.go and parser.go?

[pelletier]

Yes! It probably involves refining the dateRegexp in lexer.go and improve the tokenDate case of parseRvalue in parser.go.

[kzys]

Thanks. The changes for the lexer and parser are done. However, these "short" dates/times are defined as "local" dates/times.
https://github.com/toml-lang/toml#local-date-time

And it doesn't nicely match with Go's Time, which is more likely DateTime.
https://golang.org/pkg/time/#Time

Does it make sense to have an additional dependency to express them? Apparently there are multiple Date types, which is not great for interoperability though.
golang/go#21365

[pelletier]

I'm not sure I follow. What's the issue with short dates resulting in Time objects with tz set to local?

[kzys]

In the spec, short dates (Local Date-Time and Local Date) are defined as "without any relation to an offset or timezone".

Parsing them as Time objects is possible. But doesn't it break round-trip?

[pelletier]

Ha right, I tripped up at "are defined as "local" dates/times".

It's a tough one. Time objects would indeed break round-trip. TOML defines those date/time as civil time, so I think we should do the same. My only hesitation is, as you pointed out, there is not a single, or at least very common library to work with those.

The option that makes more sense to me is using go/civil. It does not import other dependency, seems easy to use, and makes it trivial for the user to convert to whatever type he fancies. Thoughts?

[pelletier]

The TOML 0.5.0 spec has now extended that definition.

https://github.com/toml-lang/toml/blob/master/versions/en/toml-v0.5.0.md#user-content-offset-date-time

---

Offset Date-Time

To unambiguously represent a specific instant in time, you may use an
RFC 3339 formatted date-time with offset.

odt1 = 1979-05-27T07:32:00Z
odt2 = 1979-05-27T00:32:00-07:00
odt3 = 1979-05-27T00:32:00.999999-07:00

For the sake of readability, you may replace the T delimiter between date and
time with a space (as permitted by RFC 3339 section 5.6).

odt4 = 1979-05-27 07:32:00Z

The precision of fractional seconds is implementation specific, but at least
millisecond precision is expected. If the value contains greater precision than
the implementation can support, the additional precision must be truncated, not
rounded.

Local Date-Time

If you omit the offset from an RFC 3339
formatted date-time, it will represent the given date-time without any relation
to an offset or timezone. It cannot be converted to an instant in time without
additional information. Conversion to an instant, if required, is implementation
specific.

ldt1 = 1979-05-27T07:32:00
ldt2 = 1979-05-27T00:32:00.999999

The precision of fractional seconds is implementation specific, but at least
millisecond precision is expected. If the value contains greater precision than
the implementation can support, the additional precision must be truncated, not
rounded.

Local Date

If you include only the date portion of an
RFC 3339 formatted date-time, it will
represent that entire day without any relation to an offset or timezone.

ld1 = 1979-05-27

Local Time

If you include only the time portion of an RFC
3339 formatted date-time, it will represent
that time of day without any relation to a specific day or any offset or
timezone.

lt1 = 07:32:00
lt2 = 00:32:00.999999

The precision of fractional seconds is implementation specific, but at least
millisecond precision is expected. If the value contains greater precision than
the implementation can support, the additional precision must be truncated, not
rounded.

[pelletier]

• Short-date support #298
• Local time support #318
• Local DateTime support #317

Those PRs should fully implement this spec. If anything else is missing please file a bug!