The calendar module has had the time formatting function strftime/3 for a while now, which is very useful. However, if a want to parse a time string according to a given format, I still have to resort to external libraries and for example use Timex.parse/2 and friends.
Why doesn’t the module have a strptime function (strptime(3) - Linux manual page) ? Is this still work in progress or not planned for some reason?
Calendar functionalty has been added piece by piece to elixir core. Parsing is the last larger piece still missing, but also I feel like the one most tricky to get right. Andrea Leopardi recently did a few PRs to GitHub - hrzndhrn/datix: A date-time parser using `Calendar.strftime` format strings. and I’ve heard Jose talk about it (iirc in one of the podcasts with thinking elixir), so it’s certainly on their mind.
Until then I’d just pull in datix for parsing tasks. There’s now a handful of smaller libraries, which just do a subset of datetime handling, so there’s no need to pull in the large timex library.
It’s not immediately clear to me while parsing would be considerably more difficult than formatting, but I’m sure the devil is, as usual, in the details
Thanks for pointing me to Datix and the other libraries. Currently I’m using Timex only for parsing so this sounds like a good way to replace it with a more lightweight library
I think I know which podcast episode you’re referring to. IIRC they were talking about a parsing functionality similar to some “magic” function in Rails (I believe it was this one) which tries to make sense of any time string without a predefined format. They were saying that this isn’t generally a good idea (I agree) and that something similar will likely not make it into Elixir. However, parsing from a specified format is a completely different story and something I think should make it into the core library at some point, so that’s why I asked the question.
Totally agree. Though even then there’s the question if it works only for english input (e.g. month names) or if the language can be configured, should it attempt to guess the language out of multiple configured ones, …
yeah my point was only that if I had to write the strptime function I would design it as the exact counterpart of strftime. So if strftime accepts localization options like :month_names and Co, strptime should do the same but not attempt to do anything more sophisticated.