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

Short dates support #63

Open
pelletier opened this Issue Apr 22, 2016 · 7 comments

Comments

2 participants
@pelletier
Owner

pelletier commented Apr 22, 2016

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

should all be supported.

@kzys

This comment has been minimized.

Show comment
Hide comment
@kzys

kzys Oct 17, 2017

Contributor

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

Contributor

kzys commented Oct 17, 2017

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

@pelletier

This comment has been minimized.

Show comment
Hide comment
@pelletier

pelletier Oct 17, 2017

Owner

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

Owner

pelletier commented Oct 17, 2017

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

@kzys

This comment has been minimized.

Show comment
Hide comment
@kzys

kzys Oct 18, 2017

Contributor

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

Contributor

kzys commented Oct 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pelletier

pelletier Oct 21, 2017

Owner

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

Owner

pelletier commented Oct 21, 2017

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

@kzys

This comment has been minimized.

Show comment
Hide comment
@kzys

kzys Oct 21, 2017

Contributor

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?

Contributor

kzys commented Oct 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pelletier

pelletier Oct 22, 2017

Owner

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?

Owner

pelletier commented Oct 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pelletier

pelletier Jul 18, 2018

Owner

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.

Owner

pelletier commented Jul 18, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment