-
Notifications
You must be signed in to change notification settings - Fork 160
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
Comments
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. |
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 |
It exposes those two types, along with ultimately the others listed, to the user. It replaces date instead of attempting to fix. |
It would be awesome if this could be emphasized in the doc, for example I don't see any mention |
@maggiepint I'm confused about your statement, because in the slide it says the opposite, that a local time has DST. |
@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. |
Basically my question is: Can
LocalDateTime
simply beZonedDateTime
using the user's environment timeZone as default fortimeZone
?The text was updated successfully, but these errors were encountered: