Adds international date formatting

[shutej]

No description provided.

[process-bot]

Thanks for the pull request! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[process-bot]

Thanks for the pull request! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[bowsersenior]

Please merge this pull request ASAP or similar functionality. Basic UTC support is a requirement for any serious usage. My colleagues will laugh at me if I introduce Elm to them and they find out there is no UTC functionality in it's Time/Date methods.

[bowsersenior]

Please merge this pull request ASAP or similar functionality. Basic UTC support is a requirement for any serious usage. My colleagues will laugh at me if I introduce Elm to them and they find out there is no UTC functionality in it's Time/Date methods.

[ktonon]

I agree that timezone support should be part of the core Date library, but until either this PR or #755 get merged, there is http://package.elm-lang.org/packages/elm-community/elm-time/1.0.2/Time-ZonedDateTime

[ktonon]

I agree that timezone support should be part of the core Date library, but until either this PR or #755 get merged, there is http://package.elm-lang.org/packages/elm-community/elm-time/1.0.2/Time-ZonedDateTime

[ktonon]

Actually, I don't think ZonedDateTime will cut it. It doesn't provide a way to get the current datetime! You could just use http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Date#now to get the current date, and then create a ZonedDateTime from that, but then you have no way of knowing what the timezone is in the first place!

[ktonon]

Actually, I don't think ZonedDateTime will cut it. It doesn't provide a way to get the current datetime! You could just use http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Date#now to get the current date, and then create a ZonedDateTime from that, but then you have no way of knowing what the timezone is in the first place!

[ktonon]

https://github.com/justinmimbs/elm-date-extra/blob/2.0.3/src/Date/Internal/Extract.elm#L55

Shouldn't have to go through this much trouble to get the timezone offset. Package maintainers, please merge, or at least comment on this PR or #755

[ktonon]

https://github.com/justinmimbs/elm-date-extra/blob/2.0.3/src/Date/Internal/Extract.elm#L55

Shouldn't have to go through this much trouble to get the timezone offset. Package maintainers, please merge, or at least comment on this PR or #755

[evancz]

General Comments

I have tried to explain with @process-bot how these sorts of issues are handled. I hope @shutej, @ktonon, and others will read the links in that comment that get into batching work which is elaborated on much more here.

I have also provided this document to help explain some of the near-term prioritization choices.

Specific Comments

Description: To address this issue fully, I would want to review a broad set of usage scenarios to make sure I understood all the possible needs people will have. From there, I would want to review how this is addressed in a bunch of other languages. From there, I would want to find the simplest possible API that is nice to use in practice. This is all hard to do, and as @process-bot says, a PR with a totally blank description does none of this necessary background work.

Design: Getting a UTC offset is an effect, so it likely should be handled as a Task. These API calls just get that info pretending to be a pure function, meaning this could cause test failures depending on where your CI server is running. This seems like a serious concern given than Elm only has managed effects. If the offset is part of the Date, it seems like the conversion from Time needs to take that into account.

Timing: Now, assuming that this PR was great and ready to go, we take releases of elm-lang/core very seriously. Every single library in the whole ecosystem depends on core, so it is important to be thorough. In that spirit, it makes sense to align releases of core with releases of the compiler. That means we get many weeks of testing in real codebases before it goes out to everyone in the ecosystem.

Summary

To take a step back, the big picture prioritization decisions look like this. To actually do a good release of core would take a week of testing at least, meaning a bunch of other stuff gets pushed back even though this could be batched with other testing and basically be free. Expanding the Web Platform support within Elm is already slated as "the next big project" as documented here and would include stuff like this. As I said before, I think the batching approach has been important to Elm's success, and I am very conscious that in spite of the results it has produced, this process does not suit everyone. I think it makes sense to end by reemphasizing this explanation.

I hope this also helps the folks seeing this issue on HN and wondering if there is some broader context. I also hope that it is no surprise that there is.

[evancz]

General Comments

I have tried to explain with @process-bot how these sorts of issues are handled. I hope @shutej, @ktonon, and others will read the links in that comment that get into batching work which is elaborated on much more here.

I have also provided this document to help explain some of the near-term prioritization choices.

Specific Comments

Description: To address this issue fully, I would want to review a broad set of usage scenarios to make sure I understood all the possible needs people will have. From there, I would want to review how this is addressed in a bunch of other languages. From there, I would want to find the simplest possible API that is nice to use in practice. This is all hard to do, and as @process-bot says, a PR with a totally blank description does none of this necessary background work.

Design: Getting a UTC offset is an effect, so it likely should be handled as a Task. These API calls just get that info pretending to be a pure function, meaning this could cause test failures depending on where your CI server is running. This seems like a serious concern given than Elm only has managed effects. If the offset is part of the Date, it seems like the conversion from Time needs to take that into account.

Timing: Now, assuming that this PR was great and ready to go, we take releases of elm-lang/core very seriously. Every single library in the whole ecosystem depends on core, so it is important to be thorough. In that spirit, it makes sense to align releases of core with releases of the compiler. That means we get many weeks of testing in real codebases before it goes out to everyone in the ecosystem.

Summary

To take a step back, the big picture prioritization decisions look like this. To actually do a good release of core would take a week of testing at least, meaning a bunch of other stuff gets pushed back even though this could be batched with other testing and basically be free. Expanding the Web Platform support within Elm is already slated as "the next big project" as documented here and would include stuff like this. As I said before, I think the batching approach has been important to Elm's success, and I am very conscious that in spite of the results it has produced, this process does not suit everyone. I think it makes sense to end by reemphasizing this explanation.

I hope this also helps the folks seeing this issue on HN and wondering if there is some broader context. I also hope that it is no surprise that there is.

[evancz]

As I have learned more about producing accurate date information, it seems like it is worth trying to make something like elm-community/elm-time as solid and nice to use as possible. I do not have faith that we can build on top of JavaScript's Date functions and build anything particularly nice.

[evancz]

As I have learned more about producing accurate date information, it seems like it is worth trying to make something like elm-community/elm-time as solid and nice to use as possible. I do not have faith that we can build on top of JavaScript's Date functions and build anything particularly nice.