[Bug 4040] New: templating: the date-formatting filter always expands 'numeric timezone specifier' format "%z" to "+0000"

mercurial-bugs at selenic.com mercurial-bugs at selenic.com
Tue Sep 17 19:03:29 CDT 2013


http://bz.selenic.com/show_bug.cgi?id=4040

          Priority: normal
            Bug ID: 4040
                CC: mercurial-devel at selenic.com
          Assignee: bugzilla at selenic.com
           Summary: templating: the date-formatting filter always expands
                    'numeric timezone specifier' format "%z" to "+0000"
          Severity: bug
    Classification: Unclassified
                OS: Linux
          Reporter: ytr.used-only-until-20131001-as-public-address at riseup.
                    net
          Hardware: PC
            Status: UNCONFIRMED
           Version: 2.7.1
         Component: Mercurial
           Product: Mercurial

According to "hg help templating", there is a keyword called "date" which
relates the "date information". Then, to format such a datetime, any one of
several filters is to be used. One of those filters is called "date" again.
That filter can (like all filters) be called like a function. Unlike most
filters, the "date()" function call can include an optional second parameter,
the format.

It seems that the specifics of that format aren't specified by any hg
documentation directly, though the example already suggests that the format is
passed to the standard C library's strftime (or to a similar function elsewhere
in hg or python).

In any case, during tests the format appeared to accept the specifier "%Z"
(capital letter Z) which is to return an abbreviation for a timezone name, and
more relevantly the format specifier "%z" (small letter Z) which is to return a
numeric timezone specifier.

However, it became apparent that neither of these specifiers works as expected.
Crucially, this makes it impossible to correctly use a custom format and have
the written datetime properly include correct timezone information.

In the testing log in the follow-up comment, the results were that all the date
and time elements of the written datetime matched those of the predefined
format filters (isodatesec, etc) while the numeric timezone specifier always
was "+0000".

( Additionally, the timezone abbreviation always was that of the local timezone
currently configured for the invoked hg command. (Not to be confused with the
local timezone of the datetime stamp internally stored for the commit.)
However, assuming hg doesn't and shouldn't store abbreviations with the
commits, the specifier %Z for the abbreviation arguably just shouldn't be
supported at all. And with the possible ambiguities, such abbreviations already
don't help with formatting and transmitting an unambiguous reference to UTC. )

In the tests, the expected result would be that for the %z format, the
applicable numeric timezone specifier would occur rather than "+0000". For the
"formatted date" that's "+0200" (because the commit's datetime was specified
with that, and "7200 seconds ahead of UTC" is the timezone stored internally
for the commit) and for the "formatted localdate" that's "+0400" (matching the
currently-configured local timezone, regardless the commit's internally-stored
timezone).

Basically, the "formatted" fields should numerically match the
isodatesec-formatted datetime stamps just below them.

I tested this with almost the same script some time ago using 2.6.2 already;
like 2.7.1 here it always expanded the "%z" to "+0000" in these tests.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Mercurial-devel mailing list