Re: [PATCH v4 0/9] Introduce timestamp_t for timestamps
- From
Jacob Keller <jacob.keller@gmail.com>
- Date
- Apr 24, 2017, 06:15 UTC
- Message-ID
- <CA+P7+xoZ_dTvg9b6uckD4-=hHHNE42SCApzs9QO0YddpKXCR5g@mail.gmail.com>
- In-Reply-To
- <xmqqbmrm1o1k.fsf@gitster.mtv.corp.google.com>
On Sun, Apr 23, 2017 at 8:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 28 quoted lines
> Johannes Schindelin <johannes.schindelin@gmx.de> writes: > >> Changes since v3: >> >> - fixed the fix in archive-zip.c that tried to report a too large >> timestamp (and would have reported the uninitialized time_t instead) >> >> - adjusted the so-far forgotten each_reflog() function (that was >> introduced after v1, in 80f2a6097c4 (t/helper: add test-ref-store to >> test ref-store functions, 2017-03-26)) to use timestamp_t and PRItime, >> too >> >> - removed the date_overflows() check from time_to_tm(), as it calls >> gm_time_t() which already performs that check >> >> - the date_overflows() check in show_ident_date() was removed, as we do >> not know at that point yet whether we use the system functions to >> render the date or not (and there would not be a problem in the latter >> case) > > Assuming that the list consensus is to go with a separate > timestamp_t (for that added Cc for those whose comments I saw in an > earlier round), the patches looked mostly good (I didn't read with > fine toothed comb the largest one 6/8 to see if there were > inadvertent or missed conversions from ulong to timestamp_t, > though), modulo a few minor "huh?" comments I sent separately. > > Will queue; thanks.
I think that this timestamp_t makes sense. I didn't get a chance to review the code to make sure nothing was forgotten, but I think the direction makes sense to resolve the problems with current time_t and ulong assumptions.
Thanks, Jake