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

Deal with local datetimes, dates, and times better #307

Merged
merged 1 commit into from Jul 4, 2021
Merged

Conversation

arp242
Copy link
Collaborator

@arp242 arp242 commented Jul 4, 2021

The exact behaviour of a local datetime is not precisely defined:

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.

So this is how this implementation will deal with it:

  • Use the local timezone, for example "WITA +0800" in my case.

  • However, use the new toml.Local* timezones to do so instead of
    time.Local. This has the same offset, but you can compare/use this:

    if mytime.Location() == toml.LocalTime {
    ...
    }

Without this information it's hard to know if we're dealing with a date,
time, or local datetime. How would I distinguish between a "datetime
with the TZ set to whatever my local time zone is" and "a local
datetime"? Or how do I know that the time 00:00:00 means it's not
specified at all vs. just midnight?

An alternative solution would be add this to the MetaData, but I think
this is nicer as it's part of the time.Time.

The downside is that "fmt.Println(mytime)" will print "local-datetime"
as the "timezone". I think that's okay, and actually useful as it
signals you forgot to do something with this local date. As the spec
says:

It cannot be converted to an instant in time without additional
information.

(Aside: to be honest I'm not sure this entire feature was really a good idea –
times and timezones are already hard enough, and you can represent this
kind of stuff as just strings too; but it's in there so we have to deal
with it.)

The exact behaviour of a local datetime is not precisely defined:

	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.

So this is how this implementation will deal with it:

- Use the local timezone, for example "WITA +0800" in my case.

- However, use the new toml.Local* timezones to do so instead of
  time.Local. This has the same offset, but you can compare/use this:

	if mytime.Location() == toml.LocalTime {
		...
	}

Without this information it's hard to know if we're dealing with a date,
time, or local datetime. How would I distinguish between a "datetime
with the TZ set to whatever my local time zone is" and "a local
datetime"? Or how do I know that the time 00:00:00 means it's not
specified at all vs. just midnight?

An alternative solution would be add this to the MetaData, but I think
this is nicer as it's part of the time.Time.

The downside is that "fmt.Println(mytime)" will print "local-datetime"
as the "timezone". I think that's okay, and actually useful as it
signals you forgot to do something with this local date. As the spec
says:

	It cannot be converted to an instant in time without additional
	information.

(Aside: to be honest I'm not sure this entire feature was really a good idea –
times and timezones are already hard enough, and you can represent this
kind of stuff as just strings too; but it's in there so we have to deal
with it.)
@arp242 arp242 merged commit ebe1404 into master Jul 4, 2021
@arp242 arp242 deleted the local-datetime branch July 4, 2021 12:10
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

Successfully merging this pull request may close these issues.

None yet

1 participant