git/date.c, branch v2.13.2

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

local_tzoffset: detect errors from tm_to_time_t

2016-06-20T22:08:07Z

When we want to know the local timezone offset at a given timestamp, we compute it by asking for localtime() at the given time, and comparing the offset to GMT at that time. However, there's some juggling between time_t and "struct tm" which happens, which involves calling our own tm_to_time_t(). If that function returns an error (e.g., because it only handles dates up to the year 2099), it returns "-1", which we treat as a time_t, and is clearly bogus, leading to bizarre timestamps (that seem to always adjust the time back to (time_t)(uint32_t)-1, in the year 2106). It's not a good idea for local_tzoffset() to simply die here; it would make it hard to run "git log" on a repository with funny timestamps. Instead, let's just treat such cases as "zero offset". Reported-by: Norbert Kiesel Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

date: make "local" orthogonal to date format

2015-09-03T22:45:26Z

Most of our "--date" modes are about the format of the date: which items we show and in what order. But "--date=local" is a bit of an oddball. It means "show the date in the normal format, but using the local timezone". The timezone we use is orthogonal to the actual format, and there is no reason we could not have "localized iso8601", etc. This patch adds a "local" boolean field to "struct date_mode", and drops the DATE_LOCAL element from the date_mode_type enum (it's now just DATE_NORMAL plus local=1). The new feature is accessible to users by adding "-local" to any date mode (e.g., "iso-local"), and we retain "local" as an alias for "default-local" for backwards compatibility. Signed-off-by: Jeff King Signed-off-by: John Keeping Signed-off-by: Junio C Hamano

date: check for "local" before anything else

2015-09-03T22:42:18Z

In a following commit we will make "local" orthogonal to the format. Although this will not apply to "relative", which does not use the timezone, it applies to all other formats so move the timezone conversion to the start of the function. Signed-off-by: John Keeping Signed-off-by: Junio C Hamano

introduce "format" date-mode

2015-06-29T18:39:10Z

This feeds the format directly to strftime. Besides being a little more flexible, the main advantage is that your system strftime may know more about your locale's preferred format (e.g., how to spell the days of the week). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

convert "enum date_mode" into a struct

2015-06-29T18:39:07Z

In preparation for adding date modes that may carry extra information beyond the mode itself, this patch converts the date_mode enum into a struct. Most of the conversion is fairly straightforward; we pass the struct as a pointer and dereference the type field where necessary. Locations that declare a date_mode can use a "{}" constructor. However, the tricky case is where we use the enum labels as constants, like: show_date(t, tz, DATE_NORMAL); Ideally we could say: show_date(t, tz, &{ DATE_NORMAL }); but of course C does not allow that. Likewise, we cannot cast the constant to a struct, because we need to pass an actual address. Our options are basically: 1. Manually add a "struct date_mode d = { DATE_NORMAL }" definition to each caller, and pass "&d". This makes the callers uglier, because they sometimes do not even have their own scope (e.g., they are inside a switch statement). 2. Provide a pre-made global "date_normal" struct that can be passed by address. We'd also need "date_rfc2822", "date_iso8601", and so forth. But at least the ugliness is defined in one place. 3. Provide a wrapper that generates the correct struct on the fly. The big downside is that we end up pointing to a single global, which makes our wrapper non-reentrant. But show_date is already not reentrant, so it does not matter. This patch implements 3, along with a minor macro to keep the size of the callers sane. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jc/epochtime-wo-tz'

2015-05-06T04:00:33Z

"git commit --date=now" or anything that relies on approxidate lost the daylight-saving-time offset. * jc/epochtime-wo-tz: parse_date_basic(): let the system handle DST conversion parse_date_basic(): return early when given a bogus timestamp

parse_date_basic(): let the system handle DST conversion

2015-04-15T17:25:32Z

The function parses the input to compute the broken-down time in "struct tm", and the GMT timezone offset. If the timezone offset does not exist in the input, the broken-down time is turned into the number of seconds since epoch both in the current timezone and in GMT and the offset is computed as their difference. However, we forgot to make sure tm.tm_isdst is set to -1 (i.e. let the system figure out if DST is in effect in the current timezone when turning the broken-down time to the number of seconds since epoch); it is done so at the beginning of the function, but a call to match_digit() in the function can lead to a call to gmtime_r() to clobber the field. Reported-by: Linus Torvalds Diagnosed-by: Eric Sunshine Signed-off-by: Junio C Hamano

parse_date_basic(): return early when given a bogus timestamp

2015-04-15T17:25:05Z

When the input does not have GMT timezone offset, the code computes it by computing the local and GMT time for the given timestamp. But there is no point doing so if the given timestamp is known to be a bogus one. Signed-off-by: Junio C Hamano

Merge branch 'jk/approxidate-avoid-y-d-m-over-future-dates'

2015-01-07T21:01:16Z

Traditionally we tried to avoid interpreting date strings given by the user as future dates, e.g. GIT_COMMITTER_DATE=2014-12-10 when used early November 2014 was taken as "October 12, 2014" because it is likely that a date in the future, December 10, is a mistake. Loosen this and do not tiebreak by future-ness of the date when (1) ISO-like format is used, and (2) the string can make sense interpreted as both y-m-d and y-d-m. * jk/approxidate-avoid-y-d-m-over-future-dates: approxidate: allow ISO-like dates far in the future pass TIME_DATE_NOW to approxidate future-check