microsoft
/
git
зеркало из https://github.com/microsoft/git.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
git/Documentation/date-formats.txt

32 строки
1.1 KiB
Plaintext
Исходник Обычный вид История

Document date formats accepted by parse_date() Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-03 02:49:19 +03:00
DATE FORMATS
------------
doc: mention approxidates for git-commit --date We describe the more strict date formats accepted by GIT_COMMITTER_DATE, etc, but the --date option also allows the looser approxidate formats, as well. Unfortunately we don't have a good or complete reference for this format, but let's at least mention that it _is_ looser, and give a few examples. If we ever write separate, more complete date-format documentation, we should refer to it from here. Based-on-a-patch-by: Utku Gultopu <ugultopu@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-23 23:50:58 +03:00
The `GIT_AUTHOR_DATE` and `GIT_COMMITTER_DATE` environment variables
Document date formats accepted by parse_date() Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-03 02:49:19 +03:00
support the following date formats:
Git internal format::
Correct word usage of "timezone" in "Documentation" directory "timezone" is two words, not one (i.e. "time zone" is correct). Correct this in these files: -- date-formats.txt -- git-blame.txt -- git-cvsimport.txt -- git-fast-import.txt -- git-svn.txt -- gitweb.conf.txt -- rev-list-options.txt Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-09 04:48:52 +04:00
It is `<unix timestamp> <time zone offset>`, where `<unix
Document date formats accepted by parse_date() Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-03 02:49:19 +03:00
timestamp>` is the number of seconds since the UNIX epoch.
Correct word usage of "timezone" in "Documentation" directory "timezone" is two words, not one (i.e. "time zone" is correct). Correct this in these files: -- date-formats.txt -- git-blame.txt -- git-cvsimport.txt -- git-fast-import.txt -- git-svn.txt -- gitweb.conf.txt -- rev-list-options.txt Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-09 04:48:52 +04:00
`<time zone offset>` is a positive or negative offset from UTC.
date-formats.txt: Typo fix Last time I checked, I was living in the UTC+01:00 time zone. UTC+02:00 would be Central European _Summer_ Time. Signed-off-by: Luis Ressel <aranea@aixah.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-12 19:45:02 +03:00
For example CET (which is 1 hour ahead of UTC) is `+0100`.
Document date formats accepted by parse_date() Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-03 02:49:19 +03:00
RFC 2822::
The standard email format as described by RFC 2822, for example
`Thu, 07 Apr 2005 22:13:13 +0200`.
ISO 8601::
Time and date specified by the ISO 8601 standard, for example
`2005-04-07T22:13:13`. The parser accepts a space instead of the
date.c: skip fractional second part of ISO-8601 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 <sandals@crustytoothpaste.net> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-24 18:07:31 +03:00
`T` character as well. Fractional parts of a second will be ignored,
for example `2005-04-07T22:13:13.019` will be treated as
date-formats.txt: fix list continuation The blank line before the lone "+" means it isn't detected as a list continuation, but instead renders literally, at least with AsciiDoc. Drop the empty line and, while at it, add a closing period to the preceding paragraph. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-17 21:52:16 +03:00
`2005-04-07T22:13:13`.
Document date formats accepted by parse_date() Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-03 02:49:19 +03:00
+
NOTE: In addition, the date part is accepted in the following formats:
`YYYY.MM.DD`, `MM/DD/YYYY` and `DD.MM.YYYY`.
doc: mention approxidates for git-commit --date We describe the more strict date formats accepted by GIT_COMMITTER_DATE, etc, but the --date option also allows the looser approxidate formats, as well. Unfortunately we don't have a good or complete reference for this format, but let's at least mention that it _is_ looser, and give a few examples. If we ever write separate, more complete date-format documentation, we should refer to it from here. Based-on-a-patch-by: Utku Gultopu <ugultopu@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-23 23:50:58 +03:00
ifdef::git-commit[]
In addition to recognizing all date formats above, the `--date` option
will also try to make sense of other, more human-centric date formats,
such as relative dates like "yesterday" or "last Friday at noon".
endif::git-commit[]