W dniu 2016-07-22 o 21:51, Jeff King pisze:
> The "raw" format shows a Unix epoch timestamp, but with a
> timezone tacked on. The timestamp is not _in_ that zone, but
> it is extra information about the time (by default, the zone
> the author was in).
I would say that "Unix time" (name according to Wikipedia) is
zone-less, but the information is correct.
>
> The documentation claims that "raw-local" does not work. It
> does, but the end result is rather subtle. Let's describe it
> in better detail, and test to make sure it works (namely,
> the epoch time doesn't change, but the zone does).
Subtle, and not very useful (unless you want to know your
own timezone difference)... or do we adjust timezone offset
shown across DST change for the locale?
>
> While we are rewording the documentation in this area, let's
> not use the phrase "does not work" for the remaining option,
> "--relative". It's vague; do we accept it or not? We do
> accept it, but it has no effect (which is a reasonable
> outcome).
Anyway, replacing vague "does not work" with explanation of
what is the result is a very good idea.
>
> Signed-off-by: Jeff King <peff@xxxxxxxx>
> ---
> Documentation/rev-list-options.txt | 9 ++++++---
> t/t0006-date.sh | 1 +
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
> index 5d1de06..3ec75d4 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -725,8 +725,8 @@ include::pretty-options.txt[]
> `iso-local`), the user's local time zone is used instead.
> +
> `--date=relative` shows dates relative to the current time,
> -e.g. ``2 hours ago''. The `-local` option cannot be used with
> -`--raw` or `--relative`.
> +e.g. ``2 hours ago''. The `-local` option has no effect for
> +`--relative`.
Do I understand it correctly: --relative is a short form for more
generic --date=relative (which probably should be spelled
--date-format=relative), and that --date=relative-local is the
same as --date=relative, that is *-local suffix does not change
how date is formatted?
Because I don't think you can say --relative-local ("The `-local`
option has no effect on `--relative`"), can you?
Nevertheless the proposed change is definite improvement.
> +
> `--date=local` is an alias for `--date=default-local`.
> +
> @@ -746,7 +746,10 @@ format, often found in email messages.
> +
> `--date=short` shows only the date, but not the time, in `YYYY-MM-DD` format.
> +
> -`--date=raw` shows the date in the internal raw Git format `%s %z` format.
> +`--date=raw` shows the date in the internal raw Git format `%s %z`
> +format. Note that the `-local` option does not affect the
> +seconds-since-epoch value (which is always measured in UTC), but does
> +switch the accompanying timezone value.
Which is correct, logical, and next to useless, I think.
BTW. one kind of format that Git does not support (I think) is the
varying kind, where the precision changes with the distance from now,
so that we can get most precision in limited width. That's what
`ls --long` does:
* 'Jun 29 16:47' for dates falling in current year (more precision)
* 'Nov 23 2015' for dates outside (less precision, same width)
Many other programs switch from relative to absolute time when date
in question is far in the past that relative is not very good.
> +
> `--date=format:...` feeds the format `...` to your system `strftime`.
> Use `--date=format:%c` to show the date in your system locale's
> diff --git a/t/t0006-date.sh b/t/t0006-date.sh
> index 4c8cf58..482fec0 100755
> --- a/t/t0006-date.sh
> +++ b/t/t0006-date.sh
> @@ -47,6 +47,7 @@ check_show short "$TIME" '2016-06-15'
> check_show default "$TIME" 'Wed Jun 15 16:13:20 2016 +0200'
> check_show raw "$TIME" '1466000000 +0200'
> check_show iso-local "$TIME" '2016-06-15 14:13:20 +0000'
> +check_show raw-local "$TIME" '1466000000 +0000'
>
> # arbitrary time absurdly far in the future
> FUTURE="5758122296 -0400"
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html