Change the code for deciding what's to be done about %Z to stop
passing always either a NULL or "" char * to
strbuf_addftime(). Instead pass a boolean int to indicate whether the
strftime() %Z format should be omitted, which is what this code is
actually doing.
This code grew organically between the changes in 9eafe86d58 ("Merge
branch 'rs/strbuf-addftime-zZ'", 2017-06-22) yielding an end result
that wasn't very readable. Out of context it looked as though the call
to strbuf_addstr() might be adding a custom tz_name to the string, but
actually tz_name would always be "", so the call to strbuf_addstr()
just to add an empty string to the format was pointless.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
date.c | 2 +-
strbuf.c | 5 ++---
strbuf.h | 5 +++--
3 files changed, 6 insertions(+), 6 deletions(-)
From: Jeff King <hidden> Date: 2017-06-23 14:51:09
On Fri, Jun 23, 2017 at 02:46:03PM +0000, Ævar Arnfjörð Bjarmason wrote:
Change the code for deciding what's to be done about %Z to stop
passing always either a NULL or "" char * to
strbuf_addftime(). Instead pass a boolean int to indicate whether the
strftime() %Z format should be omitted, which is what this code is
actually doing.
This code grew organically between the changes in 9eafe86d58 ("Merge
branch 'rs/strbuf-addftime-zZ'", 2017-06-22) yielding an end result
that wasn't very readable. Out of context it looked as though the call
to strbuf_addstr() might be adding a custom tz_name to the string, but
actually tz_name would always be "", so the call to strbuf_addstr()
just to add an empty string to the format was pointless.
The idea was that eventually the caller might be able to come up with a
TZ that is not blank, but is also not what strftime("%Z") would produce.
Conceivably that could be done if Git commits carried the "%Z"
information (not likely), or if we used a reverse-lookup table (also not
likely).
This closes the door on that. Since we don't have immediate plans to go
that route, I'm OK with this patch. It would be easy enough to re-open
the door if we change our minds later.
/**
* Add the time specified by `tm`, as formatted by `strftime`.
- * `tz_name` is used to expand %Z internally unless it's NULL.
* `tz_offset` is in decimal hhmm format, e.g. -600 means six hours west
* of Greenwich, and it's used to expand %z internally. However, tokens
* with modifiers (e.g. %Ez) are passed to `strftime`.
+ * `omit_strftime_tz_name` when set, means don't let `strftime` format
+ * %Z, instead do our own formatting.
Since we now always turn it into a blank string, perhaps "do our own
formatting" could be more descriptive: we convert it into the empty
string.
-Peff
On Fri, Jun 23, 2017 at 02:46:03PM +0000, Ævar Arnfjörð Bjarmason wrote:
quoted
Change the code for deciding what's to be done about %Z to stop
passing always either a NULL or "" char * to
strbuf_addftime(). Instead pass a boolean int to indicate whether the
strftime() %Z format should be omitted, which is what this code is
actually doing.
This code grew organically between the changes in 9eafe86d58 ("Merge
branch 'rs/strbuf-addftime-zZ'", 2017-06-22) yielding an end result
that wasn't very readable. Out of context it looked as though the call
to strbuf_addstr() might be adding a custom tz_name to the string, but
actually tz_name would always be "", so the call to strbuf_addstr()
just to add an empty string to the format was pointless.
The idea was that eventually the caller might be able to come up with a
TZ that is not blank, but is also not what strftime("%Z") would produce.
Conceivably that could be done if Git commits carried the "%Z"
information (not likely), or if we used a reverse-lookup table (also not
likely).
This closes the door on that. Since we don't have immediate plans to go
that route, I'm OK with this patch. It would be easy enough to re-open
the door if we change our minds later.
Closes the door on doing that via passing the char * of the prepared
custom tz_name to strbuf_addftime().
I have a WIP patch (which may not make it on-list, depending) playing
with the idea I proposed in
CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com which
just inserts the custom TZ name based on the offset inside that `if
(omit_strftime_tz_name)` branch.
That seems like a more straightforward way to do it than passing the
name to strbuf_addftime().
quoted
/**
* Add the time specified by `tm`, as formatted by `strftime`.
- * `tz_name` is used to expand %Z internally unless it's NULL.
* `tz_offset` is in decimal hhmm format, e.g. -600 means six hours west
* of Greenwich, and it's used to expand %z internally. However, tokens
* with modifiers (e.g. %Ez) are passed to `strftime`.
+ * `omit_strftime_tz_name` when set, means don't let `strftime` format
+ * %Z, instead do our own formatting.
Since we now always turn it into a blank string, perhaps "do our own
formatting" could be more descriptive: we convert it into the empty
string.
Then we'd need to change this comment again if we had some patch like
the one I mentioned above, I thought it was better to just leave this
vague enough that we didn't need to do that.
From: René Scharfe <hidden> Date: 2017-06-23 15:20:38
Am 23.06.2017 um 16:46 schrieb Ævar Arnfjörð Bjarmason:
Change the code for deciding what's to be done about %Z to stop
passing always either a NULL or "" char * to
strbuf_addftime(). Instead pass a boolean int to indicate whether the
strftime() %Z format should be omitted, which is what this code is
actually doing.
"Omitting" sounds not quite right somehow. We expand %Z to the empty
string because that's the best we can do -- which amounts to a removal,
but that's not the intent, just an implementation detail. Calling it
"handling %Z internally" would be better, I think.
quoted hunk
This code grew organically between the changes in 9eafe86d58 ("Merge
branch 'rs/strbuf-addftime-zZ'", 2017-06-22) yielding an end result
that wasn't very readable. Out of context it looked as though the call
to strbuf_addstr() might be adding a custom tz_name to the string, but
actually tz_name would always be "", so the call to strbuf_addstr()
just to add an empty string to the format was pointless.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
date.c | 2 +-
strbuf.c | 5 ++---
strbuf.h | 5 +++--
3 files changed, 6 insertions(+), 6 deletions(-)
Why const? And as written above, naming the parameter local would make
it easier to understand instead of exposing an implementation detail in
the interface.
quoted hunk
{
struct strbuf munged_fmt = STRBUF_INIT;
size_t hint = 128;
@@ -815,8 +815,7 @@ void strbuf_addftime(struct strbuf *sb, const char *fmt, const struct tm *tm, fmt++; break; case 'Z':- if (tz_name) {- strbuf_addstr(&munged_fmt, tz_name);+ if (omit_strftime_tz_name) {
Getting rid of this strbuf_addstr call is nice, but as Peff mentioned in
his reply it also reduces the flexibility of the function. While it's
unlikely to be needed I'm not convinced that we should already block
this path (even though it could be easily reopened).
From: Jeff King <hidden> Date: 2017-06-23 15:23:51
On Fri, Jun 23, 2017 at 05:13:38PM +0200, Ævar Arnfjörð Bjarmason wrote:
quoted
The idea was that eventually the caller might be able to come up with a
TZ that is not blank, but is also not what strftime("%Z") would produce.
Conceivably that could be done if Git commits carried the "%Z"
information (not likely), or if we used a reverse-lookup table (also not
likely).
This closes the door on that. Since we don't have immediate plans to go
that route, I'm OK with this patch. It would be easy enough to re-open
the door if we change our minds later.
Closes the door on doing that via passing the char * of the prepared
custom tz_name to strbuf_addftime().
I have a WIP patch (which may not make it on-list, depending) playing
with the idea I proposed in
CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com which
just inserts the custom TZ name based on the offset inside that `if
(omit_strftime_tz_name)` branch.
OK. I'd assumed that would all happen outside of strbuf_addftime(). But
if it happens inside, then I agree a flag is better.
quoted
quoted
* Add the time specified by `tm`, as formatted by `strftime`.
- * `tz_name` is used to expand %Z internally unless it's NULL.
* `tz_offset` is in decimal hhmm format, e.g. -600 means six hours west
* of Greenwich, and it's used to expand %z internally. However, tokens
* with modifiers (e.g. %Ez) are passed to `strftime`.
+ * `omit_strftime_tz_name` when set, means don't let `strftime` format
+ * %Z, instead do our own formatting.
Since we now always turn it into a blank string, perhaps "do our own
formatting" could be more descriptive: we convert it into the empty
string.
Then we'd need to change this comment again if we had some patch like
the one I mentioned above, I thought it was better to just leave this
vague enough that we didn't need to do that.
Right, if you're going to do your own formatting inside the function,
then I agree the wording should be kept. But then "omit" is not really
the right word. Isn't it "tzname_from_tz" or something?
-Peff
Why const? And as written above, naming the parameter local would make
it easier to understand instead of exposing an implementation detail in
the interface.
I think calling it "local" isn't right. That's a decision the _caller_
is making about whether to pass through %Z. But the actual
implementation is more like "should the function fill tzname based on
tz?" So some name along those lines would make sense.
In which case the caller would then pass "!mode->local" for the flag.
-Peff
Why const? And as written above, naming the parameter local would make
it easier to understand instead of exposing an implementation detail in
the interface.
I think calling it "local" isn't right. That's a decision the _caller_
is making about whether to pass through %Z. But the actual
implementation is more like "should the function fill tzname based on
tz?" So some name along those lines would make sense.
In which case the caller would then pass "!mode->local" for the flag.
We only have a single caller currently, so responsibilities can still be
shifted, and it's a bit hard to draw the line. "Here's a format and all
time information I have, expand!" is just as viable as "here's a format
and most time information, expand, and handle %Z in this particular way
when you see it!", I think.
René
From: René Scharfe <hidden> Date: 2017-06-23 16:23:25
Am 23.06.2017 um 17:23 schrieb Jeff King:
On Fri, Jun 23, 2017 at 05:13:38PM +0200, Ævar Arnfjörð Bjarmason wrote:
quoted
quoted
The idea was that eventually the caller might be able to come up with a
TZ that is not blank, but is also not what strftime("%Z") would produce.
Conceivably that could be done if Git commits carried the "%Z"
information (not likely), or if we used a reverse-lookup table (also not
likely).
This closes the door on that. Since we don't have immediate plans to go
that route, I'm OK with this patch. It would be easy enough to re-open
the door if we change our minds later.
Closes the door on doing that via passing the char * of the prepared
custom tz_name to strbuf_addftime().
I have a WIP patch (which may not make it on-list, depending) playing
with the idea I proposed in
CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com which
just inserts the custom TZ name based on the offset inside that `if
(omit_strftime_tz_name)` branch.
OK. I'd assumed that would all happen outside of strbuf_addftime(). But
if it happens inside, then I agree a flag is better.
Oh, so the interface that was meant to allow better time zone names
without having to make strbuf_addftime() even bigger than it already is
turns out to be too ugly for its purpose? I'm sorry. :(
René
Change the code for deciding what's to be done about %Z to stop
passing always either a NULL or "" char * to
strbuf_addftime(). Instead pass a boolean int to indicate whether the
strftime() %Z format should be expanded to an empty string, which is
what this code is actually doing.
This code grew organically between the changes in 9eafe86d58 ("Merge
branch 'rs/strbuf-addftime-zZ'", 2017-06-22) yielding an end result
that wasn't very readable.
Out of context it looked as though the call to strbuf_addstr() might
be adding a custom tz_name to the string, but actually tz_name would
always be "", so the call to strbuf_addstr() just to add an empty
string to the format was pointless.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
I believe this addresses the comments in the thread so far. Also Re:
René's "why const?" in a2673ce4-5cf8-6b40-d4db-8e2a49518138@web.de:
Because tzname_from_tz isn't changed in the body of the function, only
read.
date.c | 2 +-
strbuf.c | 5 ++---
strbuf.h | 5 +++--
3 files changed, 6 insertions(+), 6 deletions(-)
From: Jeff King <hidden> Date: 2017-06-23 16:37:17
On Fri, Jun 23, 2017 at 06:23:10PM +0200, René Scharfe wrote:
quoted
quoted
I have a WIP patch (which may not make it on-list, depending) playing
with the idea I proposed in
CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com which
just inserts the custom TZ name based on the offset inside that `if
(omit_strftime_tz_name)` branch.
OK. I'd assumed that would all happen outside of strbuf_addftime(). But
if it happens inside, then I agree a flag is better.
Oh, so the interface that was meant to allow better time zone names
without having to make strbuf_addftime() even bigger than it already is
turns out to be too ugly for its purpose? I'm sorry. :(
I haven't seen Ævar's patch, but I agree that if the caller did:
if (mode->local)
tzname = NULL; /* let strftime handle it */
else
tzname = fake_tz_from_offset(tz);
...
strbuf_addftime(&buf, fmt, tm, tz, tzname);
that would be pretty clean (and what I was expecting with the "I'd
assumed" above).
-Peff
From: Jeff King <hidden> Date: 2017-06-23 16:44:09
On Fri, Jun 23, 2017 at 04:36:06PM +0000, Ævar Arnfjörð Bjarmason wrote:
I believe this addresses the comments in the thread so far. Also Re:
René's "why const?" in a2673ce4-5cf8-6b40-d4db-8e2a49518138@web.de:
Because tzname_from_tz isn't changed in the body of the function, only
read.
Sure, it's not wrong. But that property is also held by 99% of the
parameters that are passed by value. It's the normal style in our code
base (and in most C code bases I know of) to never declare pass-by-value
as const. It pollutes the interface and isn't something the caller cares
about.
Without passing judgement on whether that style is good or not (though
IMHO it is), making this one case different than all the others is a bad
idea. It makes the reader wonder why it's different.
@@ -256,7 +256,7 @@ const char *show_date(timestamp_t time, int tz, const struct date_mode *mode)tm->tm_hour,tm->tm_min,tm->tm_sec,tz);elseif(mode->type==DATE_STRFTIME)strbuf_addftime(&timebuf,mode->strftime_fmt,tm,tz,-mode->local?NULL:"");+mode->local);
You flipped the boolean here. That's OK by me. But in the definition...
void strbuf_addftime(struct strbuf *sb, const char *fmt, const struct tm *tm,
- int tz_offset, const char *tz_name)
+ int tz_offset, const int tzname_from_tz)
Wouldn't tzname_from_tz only happen when we're _not_ in local mode? I
suggested that name anticipating your second patch to actually compute
it based on "tz". In local-mode it's not coming from tz, it's coming
from secret unportable magic (the combination of localtime() and
strftime()).
quoted hunk
@@ -815,8 +815,7 @@ void strbuf_addftime(struct strbuf *sb, const char *fmt, const struct tm *tm, fmt++; break; case 'Z':- if (tz_name) {- strbuf_addstr(&munged_fmt, tz_name);+ if (!tzname_from_tz) { fmt++; break; }
This logic matches your inversion in the caller, so it does the right
thing. But I think the name is wrong, as above.
On Fri, Jun 23, 2017 at 05:13:38PM +0200, Ævar Arnfjörð Bjarmason wrote:
quoted
quoted
The idea was that eventually the caller might be able to come up with a
TZ that is not blank, but is also not what strftime("%Z") would produce.
Conceivably that could be done if Git commits carried the "%Z"
information (not likely), or if we used a reverse-lookup table (also not
likely).
This closes the door on that. Since we don't have immediate plans to go
that route, I'm OK with this patch. It would be easy enough to re-open
the door if we change our minds later.
Closes the door on doing that via passing the char * of the prepared
custom tz_name to strbuf_addftime().
I have a WIP patch (which may not make it on-list, depending) playing
with the idea I proposed in
CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com which
just inserts the custom TZ name based on the offset inside that `if
(omit_strftime_tz_name)` branch.
OK. I'd assumed that would all happen outside of strbuf_addftime(). But
if it happens inside, then I agree a flag is better.
Oh, so the interface that was meant to allow better time zone names
without having to make strbuf_addftime() even bigger than it already is
turns out to be too ugly for its purpose? I'm sorry. :(
I don't think it's ugly. My motivation for sending this patch is that I
started playing with this code and was confused because I thought that
strbuf_addstr(...) actually did something to the string, but it never
did.
Since it's a purely internal API used in just one place I thought it
made sense to adjust the prototype / code to its current usage for ease
of readability, if we want to do something else with it in the future
it'll be trivial to adjust it then.
But I don't feel strongly about this patch at all, it's just a minor
fixup I submitted while reading / playing with the code.
Change the comment documenting the strbuf_addftime() function to
discuss the parameters in the order in which they appear, which makes
this easier to read than discussing them out of order.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
I though it was more readable to split out this change into its own
patch.
strbuf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Change the code for deciding what's to be done about %Z to stop
passing always either a NULL or "" char * to
strbuf_addftime(). Instead pass a boolean int to indicate whether the
strftime() %Z format should be suppressed by converting it to an empty
string, which is what this code is actually doing.
This code grew organically between the changes in 9eafe86d58 ("Merge
branch 'rs/strbuf-addftime-zZ'", 2017-06-22). The intent was to use
this API in the future to pass a custom leave the door open to pass a
custom timezone name to the function (see my [1] and related
messages).
But that's not what this code does now, and this strbuf_addstr() call
always being redundant makes it hard to understand the current
functionality. So simplify this internal API to match its use, we can
always change it in the future if it gets a different use-case.
1. CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com
(https://public-inbox.org/git/CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com/)
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
On Fri, Jun 23 2017, Jeff King jotted:
On Fri, Jun 23, 2017 at 04:36:06PM +0000, Ævar Arnfjörð Bjarmason wrote:
quoted
I believe this addresses the comments in the thread so far. Also Re:
René's "why const?" in a2673ce4-5cf8-6b40-d4db-8e2a49518138@web.de:
Because tzname_from_tz isn't changed in the body of the function, only
read.
Sure, it's not wrong. But that property is also held by 99% of the
parameters that are passed by value. It's the normal style in our code
base (and in most C code bases I know of) to never declare pass-by-value
as const. It pollutes the interface and isn't something the caller cares
about.
Without passing judgement on whether that style is good or not (though
IMHO it is), making this one case different than all the others is a bad
idea. It makes the reader wonder why it's different.
Makes sense. I wasn't trying to be snary or curt or whatever. I'd just
never noticed this pattern in the codebase.
Seems a bit odd to me to not make use of the compiler guarding against
accidental assignments and giving it a strong hint to inline the value
where possible, but whatever, makes sense to have it stylistically be
consistent. So this version does that.
@@ -256,7 +256,7 @@ const char *show_date(timestamp_t time, int tz, const struct date_mode *mode)tm->tm_hour,tm->tm_min,tm->tm_sec,tz);elseif(mode->type==DATE_STRFTIME)strbuf_addftime(&timebuf,mode->strftime_fmt,tm,tz,-mode->local?NULL:"");+mode->local);
You flipped the boolean here. That's OK by me. But in the definition...
quoted
void strbuf_addftime(struct strbuf *sb, const char *fmt, const struct tm *tm,
- int tz_offset, const char *tz_name)
+ int tz_offset, const int tzname_from_tz)
Wouldn't tzname_from_tz only happen when we're _not_ in local mode? I
suggested that name anticipating your second patch to actually compute
it based on "tz". In local-mode it's not coming from tz, it's coming
from secret unportable magic (the combination of localtime() and
strftime()).
I misread (I think) an earlier E-Mail of yours and thought this was
what you were suggesting. This version hopefully looks OK.
quoted
@@ -815,8 +815,7 @@ void strbuf_addftime(struct strbuf *sb, const char *fmt, const struct tm *tm, fmt++; break; case 'Z':- if (tz_name) {- strbuf_addstr(&munged_fmt, tz_name);+ if (!tzname_from_tz) { fmt++; break; }
This logic matches your inversion in the caller, so it does the right
thing. But I think the name is wrong, as above.
I couldn't quite parse "let suppress". I'm not sure if it was supposed
to be "let's". Probably "means to suppress the strftime..." would be
more clear. I'd probably have written it more like:
`suppress_tz_name`, when set, expands %Z internally to the empty
string rather than passing it to `strftime`.
-Peff
Change the comment documenting the strbuf_addftime() function to
discuss the parameters in the order in which they appear, which makes
this easier to read than discussing them out of order.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
strbuf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Change the code for deciding what's to be done about %Z to stop
passing always either a NULL or "" char * to
strbuf_addftime(). Instead pass a boolean int to indicate whether the
strftime() %Z format should be suppressed by converting it to an empty
string, which is what this code is actually doing.
This code grew organically between the changes in 9eafe86d58 ("Merge
branch 'rs/strbuf-addftime-zZ'", 2017-06-22). The intent was to use
this API in the future to pass a custom leave the door open to pass a
custom timezone name to the function (see my [1] and related
messages).
But that's not what this code does now, and this strbuf_addstr() call
always being redundant makes it hard to understand the current
functionality. So simplify this internal API to match its use, we can
always change it in the future if it gets a different use-case.
1. CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com
(https://public-inbox.org/git/CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com/)
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
On Sat, Jun 24, 2017 at 2:02 PM, Jeff King [off-list ref] wrote:
On Sat, Jun 24, 2017 at 11:36:35AM +0000, Ævar Arnfjörð Bjarmason wrote:
* `tz_offset` is in decimal hhmm format, e.g. -600 means six hours west
* of Greenwich, and it's used to expand %z internally. However, tokens
* with modifiers (e.g. %Ez) are passed to `strftime`.
- * `tz_name` is used to expand %Z internally unless it's NULL.
+ * `suppress_tz_name` when set, means let suppress the `strftime` %Z
+ * format and replace it with an empty string.
I couldn't quite parse "let suppress". I'm not sure if it was supposed
to be "let's". Probably "means to suppress the strftime..." would be
more clear. I'd probably have written it more like:
`suppress_tz_name`, when set, expands %Z internally to the empty
string rather than passing it to `strftime`.
Thanks. Docs fixed per your suggestion. I sent a v4 of 1/2 too, but
that's unchanged, just thought it was simpler than having just one
patch have a v4...
date.c | 2 +-
strbuf.c | 5 ++---
strbuf.h | 5 +++--
3 files changed, 6 insertions(+), 6 deletions(-)
From: Jeff King <hidden> Date: 2017-06-24 12:12:28
On Sat, Jun 24, 2017 at 12:10:23PM +0000, Ævar Arnfjörð Bjarmason wrote:
quoted
I couldn't quite parse "let suppress". I'm not sure if it was supposed
to be "let's". Probably "means to suppress the strftime..." would be
more clear. I'd probably have written it more like:
`suppress_tz_name`, when set, expands %Z internally to the empty
string rather than passing it to `strftime`.
Thanks. Docs fixed per your suggestion. I sent a v4 of 1/2 too, but
that's unchanged, just thought it was simpler than having just one
patch have a v4...
Thanks, both of the v4 patches look OK to me.
-Peff
Change the comment documenting the strbuf_addftime() function to
discuss the parameters in the order in which they appear, which makes
this easier to read than discussing them out of order.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
strbuf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Change the code for deciding what's to be done about %Z to stop
passing always either a NULL or "" char * to
strbuf_addftime(). Instead pass a boolean int to indicate whether the
strftime() %Z format should be suppressed by converting it to an empty
string, which is what this code is actually doing.
This code grew organically between the changes in 9eafe86d58 ("Merge
branch 'rs/strbuf-addftime-zZ'", 2017-06-22). The intent was to use
this API in the future to pass a custom leave the door open to pass a
custom timezone name to the function (see my [1] and related
messages).
But that's not what this code does now, and this strbuf_addstr() call
always being redundant makes it hard to understand the current
functionality. So simplify this internal API to match its use, we can
always change it in the future if it gets a different use-case.
1. CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com
(https://public-inbox.org/git/CACBZZX5OQc45fUyDVayE89rkT=+8m5S4efSXCAbCy7Upme5zLA@mail.gmail.com/)
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
On Sat, Jun 24, 2017 at 2:10 PM, Ævar Arnfjörð Bjarmason [off-list ref] wrote:
Thanks. Docs fixed per your suggestion. I sent a v4 of 1/2 too, but
that's unchanged, just thought it was simpler than having just one
patch have a v4...
Urgh, mistake on my end, sent v3 again as v4. Here's v5 with the
*actual* fixes. Sorry.
date.c | 2 +-
strbuf.c | 5 ++---
strbuf.h | 5 +++--
3 files changed, 6 insertions(+), 6 deletions(-)
From: Jeff King <hidden> Date: 2017-06-24 12:22:53
On Sat, Jun 24, 2017 at 12:14:52PM +0000, Ævar Arnfjörð Bjarmason wrote:
On Sat, Jun 24, 2017 at 2:10 PM, Ævar Arnfjörð Bjarmason [off-list ref] wrote:
quoted
Thanks. Docs fixed per your suggestion. I sent a v4 of 1/2 too, but
that's unchanged, just thought it was simpler than having just one
patch have a v4...
Urgh, mistake on my end, sent v3 again as v4. Here's v5 with the
*actual* fixes. Sorry.
Heh, I skimmed over v4 again and thought "this looks good", but the one
thing I _didn't_ read was the final hunk that actually changed from v3.
Yikes. So much for my code review skills.
-Peff
From: René Scharfe <hidden> Date: 2017-06-24 13:17:53
Am 24.06.2017 um 14:14 schrieb Ævar Arnfjörð Bjarmason:
Change the code for deciding what's to be done about %Z to stop
passing always either a NULL or "" char * to
strbuf_addftime(). Instead pass a boolean int to indicate whether the
strftime() %Z format should be suppressed by converting it to an empty
string, which is what this code is actually doing.
This code grew organically between the changes in 9eafe86d58 ("Merge
branch 'rs/strbuf-addftime-zZ'", 2017-06-22). The intent was to use
this API in the future to pass a custom leave the door open to pass a
custom timezone name to the function (see my [1] and related
messages).
"leave the door open to pass a" seems redundant.
But that's not what this code does now, and this strbuf_addstr() call
always being redundant makes it hard to understand the current
functionality. So simplify this internal API to match its use, we can
always change it in the future if it gets a different use-case.
I don't understand the confusion, but of course I'm biased. And I don't
like binary parameters in general and would use named flags or two
function names in most cases. But that aside I find the description
hard to follow (perhaps I should do something about my attention span).
Here's an attempt at a commit message that would have be easier to
understand for me:
strbuf_addstr() allows callers to pass a time zone name for expanding
%Z. The only current caller either passes the empty string or NULL,
in which case %Z is handed over verbatim to strftime(3). Replace that
string parameter with a flag controlling whether to remove %Z from the
format specification. This simplifies the code.
René