git/date.c, branch v2.16.2

Merge branch 'ab/strbuf-addftime-tzname-boolify'

2017-07-07T01:14:47Z

strbuf_addftime() is further getting tweaked. * ab/strbuf-addftime-tzname-boolify: strbuf: change an always NULL/"" strbuf_addftime() param to bool strbuf.h comment: discuss strbuf_addftime() arguments in order

strbuf: change an always NULL/"" strbuf_addftime() param to bool

2017-07-01T17:47:05Z

strbuf_addftime() 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. Commit-message-by: René Scharfe Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'rs/strbuf-addftime-zZ'

2017-06-22T21:15:25Z

As there is no portable way to pass timezone information to strftime, some output format from "git log" and friends are impossible to produce. Teach our own strbuf_addftime to replace %z and %Z with caller-supplied values to help working around this. * rs/strbuf-addftime-zZ: date: use localtime() for "-local" time formats t0006: check --date=format zone offsets strbuf: let strbuf_addftime handle %z and %Z itself

date: use localtime() for "-local" time formats

2017-06-15T21:39:15Z

When we convert seconds-since-epochs timestamps into a broken-down "struct tm", we do so by adjusting the timestamp according to the known offset and then using gmtime() to break down the result. This means that the resulting struct "knows" that it's in GMT, even though the time it represents is adjusted for a different zone. The fields where it stores this data are not portably accessible, so we have no way to override them to tell them the real zone info. For the most part, this works. Our date-formatting routines don't pay attention to these inaccessible fields, and use the same tz info we provided for adjustment. The one exception is when we call strftime(), whose %Z format reveals this hidden timezone data. We solved that by always showing the empty string for %Z. This is allowed by POSIX, but not very helpful to the user. We can't make this work in the general case, as there's no portable function for setting an arbitrary timezone (and anyway, we don't have the zone name for the author zones, only their offsets). But for the special case of the "-local" formats, we can just skip the adjustment and use localtime() instead of gmtime(). This makes --date=format-local:%Z work correctly, showing the local timezone instead of an empty string. The new test checks the result for "UTC", our default test-lib value for $TZ. Using something like EST5 might be more interesting, but the actual zone string is system-dependent (for instance, on my system it expands to just EST). Hopefully "UTC" is vanilla enough that every system treats it the same. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf: let strbuf_addftime handle %z and %Z itself

2017-06-15T21:34:37Z

There is no portable way to pass timezone information to strftime. Add parameters for timezone offset and name to strbuf_addftime and let it handle the timezone-related format specifiers %z and %Z internally. Callers can opt out for %Z by passing NULL as timezone name. %z is always handled internally -- this helps on Windows, where strftime would expand it to a timezone name (same as %Z), in violation of POSIX. Modifiers are not handled, e.g. %Ez is still passed to strftime. Use an empty string as timezone name in show_date (the only current caller) for now because we only have the timezone offset in non-local mode. POSIX allows %Z to resolve to an empty string in case of missing information. Helped-by: Ulrich Mueller Helped-by: Jeff King Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

date.c: abort if the system time cannot handle one of our timestamps

2017-04-27T04:07:40Z

We are about to switch to a new data type for time stamps that is definitely not smaller or equal, but larger or equal to time_t. So before using the system functions to process or format timestamps, let's make extra certain that they can handle what we feed them. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

timestamp_t: a new data type for timestamps

2017-04-27T04:07:39Z

Git's source code assumes that unsigned long is at least as precise as time_t. Which is incorrect, and causes a lot of problems, in particular where unsigned long is only 32-bit (notably on Windows, even in 64-bit versions). So let's just use a more appropriate data type instead. In preparation for this, we introduce the new `timestamp_t` data type. By necessity, this is a very, very large patch, as it has to replace all timestamps' data type in one go. As we will use a data type that is not necessarily identical to `time_t`, we need to be very careful to use `time_t` whenever we interact with the system functions, and `timestamp_t` everywhere else. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

PRItime: introduce a new "printf format" for timestamps

2017-04-24T03:19:15Z

Currently, Git's source code treats all timestamps as if they were unsigned longs. Therefore, it is okay to write "%lu" when printing them. There is a substantial problem with that, though: at least on Windows, time_t is *larger* than unsigned long, and hence we will want to switch away from the ill-specified `unsigned long` data type. So let's introduce the pseudo format "PRItime" (currently simply being defined to "lu") to make it easier to change the data type used for timestamps. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

parse_timestamp(): specify explicitly where we parse timestamps

2017-04-24T03:19:15Z

Currently, Git's source code represents all timestamps as `unsigned long`. In preparation for using a more appropriate data type, let's introduce a symbol `parse_timestamp` (currently being defined to `strtoul`) where appropriate, so that we can later easily switch to, say, use `strtoull()` instead. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

date: add "unix" format

2016-07-27T21:15:51Z

We already have "--date=raw", which is a Unix epoch timestamp plus a contextual timezone (either the author's or the local). But one may not care about the timezone and just want the epoch timestamp by itself. It's not hard to parse the two apart, but if you are using a pretty-print format, you may want git to show the "finished" form that the user will see. We can accomodate this by adding a new date format, "unix", which is basically "raw" without the timezone. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano