dashbitco/nimble_strftime

A simple and fast strftime-based datetime formatter

nimble_strftime's Issues

Discuss the existing options API

Hi @GuSilverFlame,

In the original proposal, we defined am_pm_names, month_names, and so on as functions. The idea of making them functions is that it makes it easy to wrap translations/localization tools around it. For example, with the current API, if we were to integrate it with Gettext, we would need 12 lookups every time we format a date to retrieve only the month names. The anonymous function would allow us to do that lazily, which would be more efficient.

Shall we move the options to the proposed API in the document? One option is to allow both lists and anonymous functions (but we should default to anonymous functions working with tuples as in the proposal, as that is more efficient).

Add tests for AM

Our tests currently only check for the PM part.

Add package and ex_doc metadata to mix.exs

See the other nimble* projects for example. :)

%u is zero padded

Per documentation we have:

u | Day of the week | 01 (monday), 07 (sunday)

However on Linux [1] we have:

%u The day of the week as a decimal, range 1 to 7, Monday being 1. See also %w. (Calculated from tm_wday.) (SU)

and on FreeBSD we have [2]:

%u is replaced by the weekday (Monday as the first day of the week) as a decimal number (1-7).

I wonder if there was a specific reason for 0-padding? If not, happy to change it.

[1] http://man7.org/linux/man-pages/man3/strftime.3.html

[2] https://www.freebsd.org/cgi/man.cgi?query=strftime&sektion=3

Is abbreviation size guaranteed to be a valid approach in all locales?

I am concerned that abbreviation_size is not a valid approach to providing abbreviations across all locales. Unfortunately, it is very hard to prove that this would be the case, so I believe abbreviated_month_names and abbreviated_week_names should be their own options (as in the original proposal).

Update the README and add LICENSE

See the other nimble* projects for example. :)

%f format behaves incorrectly

Different to other formats, the padding on %f should be a trailing pad. For example, this:

NimbleStrftime.format(~U"2019-08-15 17:07:57.001Z", "%I:%M:%S.%f %p")

is formatted as:

"05:07:57.1000 PM"

which is not correct. I believe by default it should be formatted using the padding in the datetime struct (which is the second element of the microsecond field).

So ~U"2019-08-15 17:07:57.001Z" should be padded as 57.001 but ~U"2019-08-15 17:07:57.001000Z" should be padded as 57.001000. The user can force a particular padding but I think in this case it will be more like a precision rather than padding. So if I say the "padding" is 1, we will only ever show the first digit.

How do other strftime implementations behave here?

Add examples to the format function documentation

A great opportunity to use doctests!

Include examples in the format documentation

Having some examples alongside the description will be very helpful, as in the original proposal:

https://elixirforum.com/t/proposal-strftime-based-calendar-datetime-formatting/18734

Alternatively, we can include the whole table as is (click on the pencil and then in raw and you can get the whole table to copy and paste).

Cannot use nimble_strftime in Phoenix

I get the following error:
function NimbleStrftime.format/2 is undefined (module NimbleStrftime is not available)