git/date.c, branch v2.35.2

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

Quit passing 'now' to date code

2019-09-12T18:03:51Z

Commit b841d4ff43 (Add `human` format to test-tool, 2019-01-28) added a get_time() function which allows $GIT_TEST_DATE_NOW in the environment to override the current time. So we no longer need to interpret that variable in cmd__date(). Therefore, we can stop passing the "now" parameter down through the date functions, since nobody uses them. Note that we do need to make sure all of the previous callers that took a "now" parameter are correctly using get_time(). Signed-off-by: Stephen P. Smith Signed-off-by: Junio C Hamano

completion: add more parameter value completion

2019-02-20T20:31:56Z

This adds value completion for a couple more paramters. To make it easier to maintain these hard coded lists, add a comment at the original list/code to remind people to update git-completion.bash too. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'lt/date-human'

2019-02-07T06:05:24Z

A new date format "--date=human" that morphs its output depending on how far the time is from the current time has been introduced. "--date=auto" can be used to use this new format when the output is going to the pager or to the terminal and otherwise the default format. * lt/date-human: Add `human` date format tests. Add `human` format to test-tool Add 'human' date format documentation Replace the proposed 'auto' mode with 'auto:' Add 'human' date format