Comments (23)
Millisecond resolution seems like a sane default; though I'm not sure about introducing that as a patch-level change.
Haskell's compromise makes sense, but in the interest of interop with the platform, I think it makes sense for a function in Elm to have the JS-like variant as a default, and a truncating option as an alternative, rather than the other way around.
I think our context of running in the browser comes with certain expectations, and following the principle of least astonishment; a function that at face value looks like it would do the same as toISOString
, probably should do the same.
from elm-time.
So I agree that the existing behavior is "not right", and that the best way to fix it is to extend the output to include the milliseconds. Opinions on whether this is a patch or minor level change?
from elm-time.
Merged. I'll do a bit of testing and package it in few minutes
from elm-time.
@witoldsz thanks for submitting. Would you like to submit a fix? Otherwise I'll look at it this evening.
from elm-time.
I could try, but I am not sure if I'll get time for this today. Maybe in the coming week? Let's do this: whoever get into this first, let that person announce it here :)
from elm-time.
OK, so I have started looking at it just now. Fix is a one minute task, the tests are to be fixed and one or two cases should be added. Will issue a pull req soon.
from elm-time.
@witoldsz It dawned on me to look up ISO8601; I'm making sure there's a standard for expressing milliseconds.
Haskell, for example, has formatISO8601
for generating to seconds resolution and has the following for more granular resolution:
formatISO8601Millis
formatISO8601Micros
formatISO8601Javascript
(alias forformatISO8601Millis
; see discussion below)
etc.
What's interesting is that they (Haskell) follow Mozilla standards which stops at the millisecond level but they caution that not all other browsers might be compatible.
I like Haskell's compromise:
- The "standard" formatter limits to the seconds resolution.
- The "millisecond" formatter limits to the milliseconds resolution.
In Elm's case, this would translate to:
toISO8601
toISO8601Millis
I like that solution.
Thoughts?
from elm-time.
I think it's looking for making a simple thing complicated. What would be the real use case of truncating ISO8601 date to seconds? For me it's like placing a mine, so inattentive developer can step on it and BUM, we have a new bug (hard to spot, actually).
I can't find a real case for this, really.
from elm-time.
I suspect that most users are not interested in seeing the milliseconds most of the time. And different programming languages handle it differently.
The biggest reason I can think of for adding the toISO8601Millis
method instead of modifying the existing one is that the existing behavior doesn't change; just a new capability is being added.
The new capability is, as @zwilias notes, a patch-level change, whereas modifying what toISO8601
does will have to at least, imho, be a minor-level change.
Changing existing behavior violates the principle of least astonishment.
from elm-time.
But I see the attraction of complying w/ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString
There are pros and cons either way we go.
from elm-time.
I would ask my question again: what is a possible use case for truncating millis from ISO8601 representation? I do understand truncating the date to seconds, or even minutes when showing it on the form, but who actually displays ISO8601 in the UI for end users? I do truncate to seconds when displaying time almost always, but when creating an HTTP request, I always switch to UTC/ISO.
from elm-time.
@witoldsz good point. Another point in your favor is that toISO8601
presently truncates the millisecond fraction; that leaves an ambiguity that I don't like. Such as why doesn't it round instead?
from elm-time.
I would call it a patch, but that is just me. The docs did not mention anything about rounding and truncating, so for me it's just a fix of a bug (this would actually fix my app, but yesterday I have rewritten it, so I do store the original ISO in the model as String; once this gets merged I could switch back to DateTime in my model).
from elm-time.
Thanks, I agree that a patch is a better solution also.
from elm-time.
Okay, I've developed the test for it and it mimics your failure. What do you have ready?
from elm-time.
Okay, I've developed the test for it and it mimics your failure. What do you have ready?
What do you mean? The pull request #31 includes test cases…
from elm-time.
Ahh, I hadn't seen the PR yet. Okay, I'll process it now.
from elm-time.
I have just spotted an example of toISO8601
in the /README.md
, it should be fixed as well.
from elm-time.
Just published (sorry, didn't see your comment above.). Thanks, I'll fix that. In the meantime, you have your elm-time fix in. Thanks for your fix and its tests.
from elm-time.
Thanks for your time too, it's Sunday actually :)
P.S.
I can see the new release 1.0.4, but /elm-package.json
has "version": "1.0.3"
. Is that OK for Elm package repository?
from elm-time.
Yeah, I just updated it. The procedures are not documented "airtight". I'll fix when I submit the fix for the README.md (it will be 1.0.5).
On another note, I saw 3 places in the README.md that need to be fixed; does that match w/ what you saw?
from elm-time.
Oh, and I don't think the version in the elm-time elm-package.json makes a difference for users.
from elm-time.
Updated README and published; version is now 1.0.5.
from elm-time.
Related Issues (20)
- DateTime.fromISO8601 fails to parse valid formats HOT 6
- travis build fails HOT 1
- Parsing fails when milliseconds are explicitly zero HOT 5
- Math naming of the fractional variables is wrong HOT 1
- Epoch and Millisencond HOT 1
- Timezone lost when reading from ISO 8601 HOT 2
- Confusing delta calculation HOT 1
- Beef up examples a bit HOT 1
- 1.0.11 & 1.0.12 versions produce compilation error HOT 14
- Upgrade to use version 2 of elm-community/parser-combinator HOT 1
- Problem with Etc/UTC±n timezone definitions? HOT 9
- Error parsing a valid ISO8601 date with a year less than 1000 HOT 2
- How to be with DateTimeData alias being internal? HOT 3
- [enhancement] Support unix epoch and epoch millisecond HOT 2
- Support end-of-day (hour 24) like ISO8601 HOT 1
- Range function to generate a list of dates between two dates HOT 2
- Calculate age in years HOT 5
- update for 0.19? HOT 5
- Support for time only ISO8601 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from elm-time.