dashbitco / nimble_strftime

A simple and fast strftime-based datetime formatter

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

%f format behaves incorrectly

josevalim opened this issue · comments

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?

Python and Haskell are the only ones I found with the %f format so far, Python does not accept padding or width options for it and Haskell uses it for century instead of microseconds
Also tried looking at C, C++, C#, Ruby, PHP and Perl

And how does Python behave here?

it ignores the format and treats it as a non format part of the string
example

>>> import time
>>> t = (2009, 2, 17, 17, 3, 38, 1, 48, 0)
>>> t = time.mktime(t)
>>> print time.strftime("%b %d %Y %H:%M:%S.%_2f", time.gmtime(t))
Feb 17 2009 20:03:38.%_2f

I tested all accepted formats in python(at least all documented here) and only %f behaves like that, all others accept padding and width normally

Interesting, thanks!

so just to be sure if I understand what to do, if a width and a pad are received with the microsecond option we ignore them and do the default formatting based on precision, right?

Correct!