git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Philip Oakley <philipoakley@iee.email>
To: Junio C Hamano <gitster@pobox.com>, Danh Doan <congdanhqx@gmail.com>
Cc: git@vger.kernel.org, "Brian M . Carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH v3 1/2] date.c: skip fractional second part of ISO-8601
Date: Thu, 23 Apr 2020 21:41:49 +0100	[thread overview]
Message-ID: <1861c472-7756-d433-9185-d83c03d72b9b@iee.email> (raw)
In-Reply-To: <xmqqmu72gfxu.fsf@gitster.c.googlers.com>

On 23/04/2020 20:28, Junio C Hamano wrote:
> Danh Doan <congdanhqx@gmail.com> writes:
>
>>>>  		if (num < 25 && num2 >= 0 && num2 < 60 && num3 >= 0 && num3 <= 60) {
>>>>  			tm->tm_hour = num;
>>>>  			tm->tm_min = num2;
>>> And after all that is done, if <num2> (and others) are within a
>>> reasonable range, we use that as HH:MM:SS.  
>>>
>>> OK.  If <num2> (or <num3>, or even <num> for that matter) weren't
>>> reasonable, is it still sensible to discard the fractional part?
>>> The answer is not immediately obvious to me.
>>>
>>> To be safe, it might make sense to extract a helper function from
>>> the next conditional, i.e.
>>>
>>> static int is_hms(long num1, long num2, long num3)
>> I'll make it `is_time` on par with is_date check.
> That is probably a lot more readable name than is_hms().  

I didn't immediately recognise hms and ymd (below) as abbreviations.
>
> I do not worry too much if the name is not "on par with" it, though,
> because is_date() does more than just "check", as you noticed below,
> unlike the "is hour-minute-seconds are within reasonable range?"
> check.
>
>> I'll look into it and check if int or long is suitable for parameter's
>> type.
>>
>>> {
>>> 	return (0 <= num1 && num1 < 25 &&
>>> 		0 <= num2 && num2 < 60 &&
>>> 		0 <= num3 && num3 <= 60);
>> Does it worth to add an explicit comment that we intentionally ignore
>> the old-and-defective 2nd leap seconds (i.e. second with value 61)?
>>
>> I saw in one of your previous email doubting if we should check for
>> `num3 <= 61` or not.
> I wrote that without checking anything, even what our own code does.
> As the existing code seems to want to work only with a second part
> that is 60 or less, not allowing a minute with 62 seconds, I think
> sticking to that and saying "0 <= num3 && num3 <= 60" is good.
>
>>> }
>>>
>>> and use it in the new "else if" block like so?
>>>
>>>
>>> 	} else if (*end == '.' && isdigit(end[1]) &&
>>> 		   is_date(tm->tm_year, tm->tm_mon, tm->tm_mday, NULL, now, tm) &&
>> When running into this, the code patch for non-approxidate hasn't
>> initialised value for now, yet.
> We may want to separate the logic that relies on the value of 'now'
> and 'now_tm->tm_year' out of is_date() to make it more easily
> reusable.  In this generic codepath, for example, we do not
> necessarily want to say "we refuse to parse timestamp that is 10
> days or more into the future".
>
> The longer I stare at is_date(), the more I am inclined to say it is
> a bit of impedance mismatch, and we instead should have the is_hms()
> helper as I suggested in the message you are responding to, plus
> something like:

Would is_hhmmss() and is_yyyymmdd() be more obvious abbreviations for
most readers?

Now that I type them, they do feel that bit too long... , as naming is
hard, maybe stick with the yms and hms, though I do keep wanting to type
ytd for the former..
>
> static int is_ymd(int year, int month, int day)
> {
>         /* like tm_to_time_t(), we only work between 1970-2099 */
> 	static const int days_in_month[] = {
> 		31, 28, 31, 30, ..., 31
> 	};
>
> 	return !(year < 1970 || 2100 <= year ||
> 		month <= 0 || 13 <= month ||
> 		day <= 0 || year / 4 + days_in_month[month-1] <= day);
> }
>
> and use it here.  I am not sure if we can reuse this inside
> is_date(), but if we can do so that would be good (and if we cannot,
> that is fine, too).
>
> Thanks.
--
Philip

  reply	other threads:[~2020-04-23 20:42 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14  0:03 Mishandling of fractional seconds in ISO 8601 format brian m. carlson
2020-04-14  9:31 ` [PATCH 0/2] More ISO-8601 support Đoàn Trần Công Danh
2020-04-14  9:31   ` [PATCH 1/2] date.c: allow fractional second part of ISO-8601 Đoàn Trần Công Danh
2020-04-14 20:16     ` Jeff King
2020-04-15  2:15       ` Danh Doan
2020-04-14 20:17     ` Jeff King
2020-04-14 23:49       ` brian m. carlson
2020-04-15  2:17         ` Danh Doan
2020-04-14  9:31   ` [PATCH 2/2] date.c: allow compact version of ISO-8601 datetime Đoàn Trần Công Danh
2020-04-14 20:24     ` Jeff King
2020-04-15  2:12       ` Danh Doan
2020-04-15 15:03       ` Junio C Hamano
2020-04-15 15:41         ` Jeff King
2020-04-15 15:58           ` Junio C Hamano
2020-04-16 11:16           ` Danh Doan
2020-04-14 23:45   ` [PATCH 0/2] More ISO-8601 support brian m. carlson
2020-04-15  3:31   ` [PATCH v2 " Đoàn Trần Công Danh
2020-04-15  3:31     ` [PATCH v2 1/2] date.c: skip fractional second part of ISO-8601 Đoàn Trần Công Danh
2020-04-15 10:17       ` Torsten Bögershausen
2020-04-16 10:04         ` Danh Doan
2020-04-15  3:31     ` [PATCH v2 2/2] date.c: allow compact version of ISO-8601 datetime Đoàn Trần Công Danh
2020-04-22 13:15   ` [PATCH v3 0/2] More ISO-8601 support Đoàn Trần Công Danh
2020-04-22 13:15     ` [PATCH v3 1/2] date.c: skip fractional second part of ISO-8601 Đoàn Trần Công Danh
2020-04-22 17:05       ` Junio C Hamano
2020-04-23  1:18         ` Danh Doan
2020-04-23 19:28           ` Junio C Hamano
2020-04-23 20:41             ` Philip Oakley [this message]
2020-04-24  0:07               ` Danh Doan
2020-04-24  0:46                 ` Junio C Hamano
2020-04-24 17:32                   ` Philip Oakley
2020-04-24 17:30                 ` Philip Oakley
2020-04-22 13:15     ` [PATCH v3 2/2] date.c: allow compact version of ISO-8601 datetime Đoàn Trần Công Danh
2020-04-22 17:17       ` Junio C Hamano
2020-04-23  1:20         ` Danh Doan
2020-04-23 13:52   ` [PATCH v4 0/4] More ISO-8601 support Đoàn Trần Công Danh
2020-04-23 13:52     ` [PATCH v4 1/4] date.c: s/is_date/set_date/ Đoàn Trần Công Danh
2020-04-23 20:08       ` Junio C Hamano
2020-04-23 13:52     ` [PATCH v4 2/4] date.c: validate and set time in a helper function Đoàn Trần Công Danh
2020-04-23 20:18       ` Junio C Hamano
2020-04-24 11:43         ` Danh Doan
2020-04-24 20:29           ` Junio C Hamano
2020-04-23 13:52     ` [PATCH v4 3/4] date.c: skip fractional second part of ISO-8601 Đoàn Trần Công Danh
2020-04-23 20:29       ` Junio C Hamano
2020-04-23 13:52     ` [PATCH v4 4/4] date.c: allow compact version of ISO-8601 datetime Đoàn Trần Công Danh
2020-04-24 15:07   ` [PATCH v5 0/4] More ISO-8601 support Đoàn Trần Công Danh
2020-04-24 15:07     ` [PATCH v5 1/4] date.c: s/is_date/set_date/ Đoàn Trần Công Danh
2020-04-24 15:07     ` [PATCH v5 2/4] date.c: validate and set time in a helper function Đoàn Trần Công Danh
2020-04-24 15:07     ` [PATCH v5 3/4] date.c: skip fractional second part of ISO-8601 Đoàn Trần Công Danh
2020-04-24 15:07     ` [PATCH v5 4/4] date.c: allow compact version of ISO-8601 datetime Đoàn Trần Công Danh

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=1861c472-7756-d433-9185-d83c03d72b9b@iee.email \
    --to=philipoakley@iee.email \
    --cc=congdanhqx@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sandals@crustytoothpaste.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).