git/date.c, branch v2.37.2

date API: add and use a date_mode_release()

2022-02-16T17:40:00Z

Fix a memory leak in the parse_date_format() function by providing a new date_mode_release() companion function. By using this in "t/helper/test-date.c" we can mark the "t0006-date.sh" test as passing when git is compiled with SANITIZE=leak, and whitelist it to run under "GIT_TEST_PASSING_SANITIZE_LEAK=true" by adding "TEST_PASSES_SANITIZE_LEAK=true" to the test itself. The other tests that expose this memory leak (i.e. take the "mode->type == DATE_STRFTIME" branch in parse_date_format()) are "t6300-for-each-ref.sh" and "t7004-tag.sh". The former is due to an easily fixed leak in "ref-filter.c", and brings the failures in "t6300-for-each-ref.sh" down from 51 to 48. Fixing the remaining leaks will have to wait until there's a release_revisions() in "revision.c", as they have to do with leaks via "struct rev_info". There is also a leak in "builtin/blame.c" due to its call to parse_date_format() to parse the "blame.date" configuration. However as it declares a file-level "static struct date_mode blame_date_mode" to track the data, LSAN will not report it as a leak. It's possible to get valgrind(1) to complain about it with e.g.: valgrind --leak-check=full --show-leak-kinds=all ./git -P -c blame.date=format:%Y blame README.md But let's focus on things LSAN complains about, and are thus observable with "TEST_PASSES_SANITIZE_LEAK=true". We should get to fixing memory leaks in "builtin/blame.c", but as doing so would require some re-arrangement of cmd_blame() let's leave it for some other time. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

date API: provide and use a DATE_MODE_INIT

2022-02-16T17:40:00Z

Provide and use a DATE_MODE_INIT macro. Most of the users of struct date_mode" use it via pretty.h's "struct pretty_print_context" which doesn't have an initialization macro, so we're still bound to being initialized to "{ 0 }" by default. But we can change the couple of callers that directly declared a variable on the stack to instead use the initializer, and thus do away with the "mode.local = 0" added in add00ba2de9 (date: make "local" orthogonal to date format, 2015-09-03). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

date API: create a date.h, split from cache.h

2022-02-16T17:40:00Z

Move the declaration of the date.c functions from cache.h, and adjust the relevant users to include the new date.h header. The show_ident_date() function belonged in pretty.h (it's defined in pretty.c), its two users outside of pretty.c didn't strictly need to include pretty.h, as they get it indirectly, but let's add it to them anyway. Similarly, the change to "builtin/{fast-import,show-branch,tag}.c" isn't needed as far as the compiler is concerned, but since they all use the "DATE_MODE()" macro we now define in date.h, let's have them include it. We could simply include this new header in "cache.h", but as this change shows these functions weren't common enough to warrant including in it in the first place. By moving them out of cache.h changes to this API will no longer cause a (mostly) full re-build of the project when "make" is run. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

strbuf_addftime(): handle "%s" manually

2021-11-04T19:38:09Z

The strftime() function has a non-standard "%s" extension, which prints the number of seconds since the epoch. But the "struct tm" we get has already been adjusted for a particular time zone; going back to an epoch time requires knowing that zone offset. Since strftime() doesn't take such an argument, round-tripping to a "struct tm" and back to the "%s" format may produce the wrong value (off by tz_offset seconds). Since we're already passing in the zone offset courtesy of c3fbf81a85 (strbuf: let strbuf_addftime handle %z and %Z itself, 2017-06-15), we can use that same value to adjust our epoch seconds accordingly. Note that the description above makes it sound like strftime()'s "%s" is useless (and really, the issue is shared by mktime(), which is what strftime() would use under the hood). But it gets the two cases for which it's designed correct: - the result of gmtime() will have a zero offset, so no adjustment is necessary - the result of localtime() will be offset by the local zone offset, and mktime() and strftime() are defined to assume this offset when converting back (there's actually some magic here; some implementations record this in the "struct tm", but we can't portably access or manipulate it. But they somehow "know" whether a "struct tm" is from gmtime() or localtime()). This latter point means that "format-local:%s" actually works correctly already, because in that case we rely on the system routines due to 6eced3ec5e (date: use localtime() for "-local" time formats, 2017-06-15). Our problem comes when trying to show times in the author's zone, as the system routines provide no mechanism for converting in non-local zones. So in those cases we have a "struct tm" that came from gmtime(), but has been manipulated according to our offset. The tests cover the broken round-trip by formatting "%s" for a time in a non-system timezone. We use the made-up "+1234" here, which has two advantages. One, we know it won't ever be the real system zone (and so we're actually testing a case that would break). And two, since it has a minute component, we're testing the full decoding of the +HHMM zone into a number of seconds. Likewise, we test the "-1234" variant to make sure there aren't any sign mistakes. There's one final test, which covers "format-local:%s". As noted, this already passes, but it's important to check that we didn't regress this case. In particular, the caller in show_date() is relying on localtime() to have done the zone adjustment, independent of any tz_offset we compute ourselves. These should match up, since our local_tzoffset() is likewise built around localtime(). But it would be easy for a caller to forget to pass in a correct tz_offset to strbuf_addftime(). Fortunately show_date() does this correctly (it has to because of the existing handling of %z), and the test continues to pass. So this one is just future-proofing against a change in our assumptions. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

comments: avoid using the gender of our users

2021-06-16T02:25:11Z

We generally avoid specifying the gender of our users in order to be more inclusive, but sometimes a few slip by due to habit. Since by doing a little bit of rewording we can avoid this irrelevant detail, let's do so. Inspired-by: Derrick Stolee Helped-by: Ævar Arnfjörð Bjarmason Signed-off-by: Felipe Contreras Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

date.c: allow compact version of ISO-8601 datetime

2020-04-24T21:06:09Z

Signed-off-by: Đoàn Trần Công Danh Signed-off-by: Junio C Hamano

date.c: skip fractional second part of ISO-8601

2020-04-24T21:06:09Z

git-commit(1) says ISO-8601 is one of our supported date format. ISO-8601 allows timestamps to have a fractional number of seconds. We represent time only in terms of whole seconds, so we never bothered parsing fractional seconds. However, it's better for us to parse and throw away the fractional part than to refuse to parse the timestamp at all. And refusing parsing fractional second part may confuse the parse to think fractional and timezone as day and month in this example: 2008-02-14 20:30:45.019-04:00 While doing this, make sure that we only interpret the number after the second and the dot as fractional when and only when the date is known, since only ISO-8601 allows the fractional part, and we've taught our users to interpret "12:34:56.7.days.ago" as a way to specify a time relative to current time. Reported-by: Brian M. Carlson Helped-by: Junio C Hamano Signed-off-by: Đoàn Trần Công Danh Signed-off-by: Junio C Hamano

date.c: validate and set time in a helper function

2020-04-24T21:06:09Z

In a later patch, we will reuse this logic, move it to a helper, now. While we're at it, explicit states that we intentionally ignore old-and-defective 2nd leap second. Signed-off-by: Đoàn Trần Công Danh Signed-off-by: Junio C Hamano

date.c: s/is_date/set_date/

2020-04-23T20:22:00Z

The function is_date, confusingly also set tm_year. tm_mon, and tm_mday after validating input. Rename to set_date to reflect its real usage. Also, change return value is 0 on success and -1 on failure following our convention on function do some real work. Signed-off-by: Đoàn Trần Công Danh Signed-off-by: Junio C Hamano

date.c: switch to reentrant {gm,local}time_r

2019-11-30T21:50:48Z

Originally, git was intended to be single-thread executable. `gmtime(3)' and `localtime(3)' can be used in such codebase for cleaner code. Overtime, we're employing multithread in our code base. Let's phase out `gmtime(3)' and `localtime(3)' in favour of `gmtime_r(3)' and `localtime_r(3)'. Signed-off-by: Doan Tran Cong Danh Signed-off-by: Junio C Hamano