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

Do we need two: LocalDateTime and ZonedDateTime? #2

Closed
rxaviers opened this issue Mar 16, 2017 · 6 comments
Closed

Do we need two: LocalDateTime and ZonedDateTime? #2

rxaviers opened this issue Mar 16, 2017 · 6 comments

Comments

@rxaviers
Copy link
Member

rxaviers commented Mar 16, 2017

Basically my question is: Can LocalDateTime simply be ZonedDateTime using the user's environment timeZone as default for timeZone?

@maggiepint
Copy link
Member

Local date time is actually context-less, it has no time zone. The reason the type exists is to make it clear when you do operations, that you have no time zone information and thus things like DST transitions would be missed. There is no way to convert from a local date time to a point on the global timeline (UTC). I'll clarify this in the spec.

@rxaviers
Copy link
Member Author

May I re-use this same issue to ask you for another clarification? Perhaps it's a dump question, but what's the goal of this proposal, is it to expose these two temporal.LocalDateTime and temporal.ZonedDateTime to the user or is this an internal thing that would power Date to support timeZone and calendars other than gregorian?

@maggiepint
Copy link
Member

It exposes those two types, along with ultimately the others listed, to the user. It replaces date instead of attempting to fix.

@rxaviers
Copy link
Member Author

It would be awesome if this could be emphasized in the doc, for example I don't see any mention Date would be replaced by the two. Thanks.

@rxaviers
Copy link
Member Author

Local date time is actually context-less, it has no time zone. The reason the type exists is to make it clear when you do operations, that you have no time zone information and thus things like DST transitions would be missed.

@maggiepint I'm confused about your statement, because in the slide it says the opposite, that a local time has DST.

screen shot 2017-03-23 at 6 55 04 pm

https://docs.google.com/presentation/d/1b6gTBphc-QEYE6rqYZ6VkFDRLE8K-EDx464tGfZ-Q6Q/edit#slide=id.g1d3b2863a0_0_70

@maggiepint
Copy link
Member

@rxaviers we have some terminology mush going on here. This slide isn't talking about the type LocalTime. It's just talking about the concept of local time - which is time in a specific place. Not sure how to better clarify that for you - it is a little weird that the common terminology in use doesn't exactly match the type names.

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