Why does the Calendar module have a strftime function but no strptime function?

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. · GitHub 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.

Thanks @LostKobrakai

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.

Good to know this is in the making!

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, …

A DateTimeParser without a predefined format is also available, see DateTimeParser - Parse DateTime, NaiveDateTime, Time, or Date from strings

well we could say: if it’s not supported when formatting, then it’s not going to be supported when parsing either.

Localization is supported for formatting via the options passed in.

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.