All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Đoàn Trần Công Danh" <congdanhqx@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Phil Hord <phil.hord@gmail.com>,
	git@vger.kernel.org, plavarre@purestorage.com
Subject: [PATCH] fixup! date.c: allow ISO 8601 reduced precision times
Date: Mon, 9 Jan 2023 18:29:17 +0700	[thread overview]
Message-ID: <Y7v6jThT9GQ8Oav8@danh.dev> (raw)
In-Reply-To: <xmqqbkn8um9q.fsf@gitster.g>

On 2023-01-09 17:48:01+0900, Junio C Hamano <gitster@pobox.com> wrote:
> Phil Hord <phil.hord@gmail.com> writes:
> 
> > Do you have any suggestions about how I can better alleviate your
> > concerns?  I don't think there are real regressions here and I tried
> > to explain why.
> 
> Other than "including it in a released version and waiting for
> people to scream", I do not think there is.  The "next" branch was
> meant to be a test ground for these new features by letting
> volunteer users to use it in their everyday development, and the
> hope was that we can catch regressions by cooking risky topics
> longer than usual in there, but we haven't been very successful, I
> have to say.

While I think we shouldn't care much about ISO-8601, we should declare
that we're only conformed to RFC-3339 format instead.

Below fixup could limit the change to only ISO-8601 strings
I'm not entirely sure if this heuristics would break those people with
00:00:00.1234 timestamp or not (the added test cases shows that this
change doesn't break ISO-8601 parsing, but I don't know).

On top of Hord's patch + Junio's next, all tests pass.
----8<----

Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
---
 date.c          | 21 +++++++++++++--------
 t/t0006-date.sh |  3 ++-
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/date.c b/date.c
index b011b9d6b3..19e6787aef 100644
--- a/date.c
+++ b/date.c
@@ -493,6 +493,12 @@ static int match_alpha(const char *date, struct tm *tm, int *offset)
 		return 2;
 	}
 
+	/* ISO-8601 allows yyyymmDD'T'HHMMSS, with less precision */
+	if (*date == 'T' && isdigit(date[1])) {
+		tm->tm_hour = tm->tm_min = tm->tm_sec = 0;
+		return strlen("T");
+	}
+
 	/* BAD CRAP */
 	return skip_alpha(date);
 }
@@ -639,15 +645,14 @@ static inline int nodate(struct tm *tm)
 }
 
 /*
- * Have we filled in any part of the time yet?
- * We just do a binary 'and' to see if the sign bit
- * is set in all the values.
+ * Have we seen an ISO-8601-alike date, i.e. 20220101T0,
+ * In those special case, those fields have been set to 0
  */
-static inline int notime(struct tm *tm)
+static inline int maybeiso8601(struct tm *tm)
 {
-	return (tm->tm_hour &
-		tm->tm_min &
-		tm->tm_sec) < 0;
+	return tm->tm_hour == 0 &&
+		tm->tm_min == 0 &&
+		tm->tm_sec == 0;
 }
 
 /*
@@ -704,7 +709,7 @@ static int match_digit(const char *date, struct tm *tm, int *offset, int *tm_gmt
 	/* 4 digits, compact style of ISO-8601's time: HHMM */
 	/* 2 digits, compact style of ISO-8601's time: HH */
 	if (n == 8 || n == 6 ||
-		(!nodate(tm) && notime(tm) &&
+		(!nodate(tm) && maybeiso8601(tm) &&
 		(n == 4 || n == 2))) {
 		unsigned int num1 = num / 10000;
 		unsigned int num2 = (num % 10000) / 100;
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index 16fb0bf4bd..130207fc04 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -93,7 +93,8 @@ check_parse '20080214T20:30' '2008-02-14 20:30:00 +0000'
 check_parse '20080214T20' '2008-02-14 20:00:00 +0000'
 check_parse '20080214T203045' '2008-02-14 20:30:45 +0000'
 check_parse '20080214T2030' '2008-02-14 20:30:00 +0000'
-check_parse '20080214T20' '2008-02-14 20:00:00 +0000'
+check_parse '20080214T000000.20' '2008-02-14 00:00:00 +0000'
+check_parse '20080214T00:00:00.20' '2008-02-14 00:00:00 +0000'
 check_parse '20080214T203045-04:00' '2008-02-14 20:30:45 -0400'
 check_parse '20080214T203045 -04:00' '2008-02-14 20:30:45 -0400'
 check_parse '20080214T203045.019-04:00' '2008-02-14 20:30:45 -0400'

-- 
Danh

  parent reply	other threads:[~2023-01-09 11:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-16  3:36 [PATCH] date.c: allow ISO 8601 reduced precision times Phil Hord
2022-12-16  4:23 ` Junio C Hamano
2022-12-16 18:38   ` Phil Hord
2023-01-09  6:41     ` Phil Hord
2023-01-09  8:48       ` Junio C Hamano
2023-01-09  9:16         ` Junio C Hamano
2023-01-09 18:30           ` Phil Hord
2023-01-09 11:29         ` Đoàn Trần Công Danh [this message]
2023-01-09 12:29           ` [PATCH] date.c: limit less precision ISO-8601 with its marker Đoàn Trần Công Danh
2023-01-09 18:57             ` Phil Hord
2023-01-11  0:10 ` [PATCH v2] date.c: allow ISO 8601 reduced precision times Đoàn Trần Công Danh
2023-01-13 19:50   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y7v6jThT9GQ8Oav8@danh.dev \
    --to=congdanhqx@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phil.hord@gmail.com \
    --cc=plavarre@purestorage.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.