Closed lohmander closed 6 years ago
At first I considered adding a toFormat method. But then what format: C strftime, Golang, YYYY-MM-DD, etc?
More than once I have made a mistake with strftime using an M
when I wanted an m
or vice-versa.
Using a function with the Time record it would be clear what the expected format is.
So instead of ISO8601.toFormat "%H:%M" time
your would formatHourMinute time
where
formatHourMinute : Time -> String
formatHourMinute time =
String.join ""
[ fmt time.hour
, ":"
, fmt time.minute
]
What about an Extras package that includes some helper functions to aid in formatting? Then authors can quickly make their own toString, toFormat, etc functions.
WDYT?
Hm, yeah that's a valid point for sure.
I think an Extras package sounds like a good idea. I'm not sure if this is just me being overly enthusiastic about function composition, but how about making a bunch of helpers to compose your own format like you said, but with an API looking something like this
formatHourMinute : Time -> String
formatHourMinute =
formatter (hour >> str ":" >> minute)
formatYMD : Time -> String
formatYMD =
formatter (year >> str "-" >> month >> str "-" >> day)
What do you think? I think it looks quite nice and clear. Or would you prefer a more "manual" approach?
I am not going to have time to implement anything in the near term. Do you want to take a stab at a simple formatting package that solves your problem(s)? At the very least you should have something useful for yourself.
I created an experimental branch with the formatting code in ISO8601.Formatter (it is also simpler) https://github.com/jweir/elm-iso8601/tree/exp/formatter
@jweir I replied to your comments on the PR 🍻
@lohmander at this point I am not going to add the formatting. I am starting to finally use this package for a real app. As I do, and have this package interact with other packages, I hope to learn more about its flaws and what it needs.
Also, my inclination is that Elm core should provide a Date (or DateTime) record like the one iso-8601 produces. Then package authors can have a standard model to work with for formatters, parsers, localization, calendars, datepickers, etc.
Ok, merged your formatter into a new branch track/formatter
.
I made some changes and hid the underlying Time record. So its fields are no longer publicly accessible. This means having a formatter is much more important (my prior method of formatting strings don't work anymore).
@jweir Nice! How do you wanna proceed with this feature now?
I'd like to have the option to specify the output format of a date string. However I am not sure if it is appropriate for a library specifically targeted towards ISO8601.
What I had in mind was using some format similar to http://strftime.org/
I'd be willing to take a look at a basic implementation if you/we think this is worth doing. I think it'd be enough to just implement a subset of the different formatting variables. I think all of the named days and months could the left out (since these would preferably be available in multiple languages if added).