git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
	git@vger.kernel.org
Subject: Re: [PATCH 0/6] Use time_t
Date: Wed, 1 Mar 2017 01:59:34 +0100	[thread overview]
Message-ID: <876bb673-ae8c-64bb-6a4d-385c84fb22d3@web.de> (raw)
In-Reply-To: <alpine.DEB.2.20.1703010000260.3767@virtualbox>

Am 01.03.2017 um 00:10 schrieb Johannes Schindelin:
> Hi René,
>
> On Tue, 28 Feb 2017, René Scharfe wrote:
>
>> Am 28.02.2017 um 21:54 schrieb Johannes Schindelin:
>>>
>>> On Tue, 28 Feb 2017, Junio C Hamano wrote:
>>>
>>>> René Scharfe <l.s.r@web.de> writes:
>>>>
>>>>> Am 28.02.2017 um 15:28 schrieb Jeff King:
>>>>>
>>>>>> It looks from the discussion like the sanest path forward is our
>>>>>> own signed-64bit timestamp_t. That's unfortunate compared to
>>>>>> using the standard time_t, but hopefully it would reduce the
>>>>>> number of knobs (like TIME_T_IS_INT64) in the long run.
>>>>>
>>>>> Glibc will get a way to enable 64-bit time_t on 32-bit platforms
>>>>> eventually
>>>>> (https://sourceware.org/glibc/wiki/Y2038ProofnessDesign).  Can
>>>>> platforms that won't provide a 64-bit time_t by 2038 be actually
>>>>> used at that point?  How would we get time information on them?
>>>>> How would a custom timestamp_t help us?
>>>>
>>>> That's a sensible "wait, let's step back a bit".  I take it that you
>>>> are saying "time_t is just fine", and I am inclined to agree.
>>>>
>>>> Right now, they may be able to have future timestamps ranging to
>>>> year 2100 and switching to time_t would limit their ability to
>>>> express future time to 2038 but they would be able to express
>>>> timestamp in the past to cover most of 20th century.  Given that
>>>> these 32-bit time_t software platforms will die off before year 2038
>>>> (either by underlying hardware getting obsolete, or software updated
>>>> to handle 64-bit time_t), the (temporary) loss of 2038-2100 range
>>>> would not be too big a deal to warrant additional complexity.
>>>
>>> You seem to assume that time_t is required to be signed. But from my
>>> understanding that is only guaranteed by POSIX, not by ISO C.
>>>
>>> We may very well buy ourselves a ton of trouble if we decide to switch
>>> to `time_t` rather than to `int64_t`.
>>
>> True, and time_t doesn't even have to be an integer type.  But which
>> platforms capable of running git use something else than int32_t or
>> int64_t?
>
> That kind of thinking is dangerous. We don't know what platforms are
> running Git, and we have a very clear example how we got it very wrong
> recently, when we broke building with musl by requiring REG_STARTEND
> support [*1*].

In general that's true, and if nobody can add to the list (glibc: 
int32_t on 32-bit platforms, int64_t on 64-bit platforms for now; 
NetBSD, OpenBSD, Windows int64_t) then we shouldn't make assumptions 
about time_t that go beyond the C standard -- at least not without 
verifying them, e.g. with asserts or tests.  I'd especially be 
interested in hearing about platforms that use a floating point type.

Systems lacking REG_STARTEND can use compat/regex/ -- that's doesn't 
sound too bad.  (I didn't follow the original discussion too closely, 
and don't mean to open it up again.)

> So why gamble? If we switch to uint64_t, it would definitely provide the
> smoothest upgrade path. It is what the code assumed implicitly when we
> broke 32-bit in v2.9.1.

We can assume that time_t exists everywhere and is used by functions 
like gettimeofday(2) and localtime(3).  Why invent our own layer on top? 
  What would it be able to do that time_t alone can't?  I understand a 
need to handle times before 1970 for historical documents, but what good 
would it do to have the ability to handle dates beyond 2038, today?

Platforms that don't use the next two decades to provide a time_t that 
can store the current time by then will have bigger problems than a 
crippled git.

> If anybody really wants to support negative timestamps, it should be done
> on top of my work. My current patch series does not even start to try to
> address the ramifications of negative timestamps (see e.g. the use of
> strtoull() for parsing). It is quite unreasonable to ask for such a
> fundamental design change when it could very easily be done incrementally
> instead, when needed, by someone who needs it.

I'm confused.  Your patch series converts to time_t.  Why not use it? 
That would prepare ourselves for the bright future when we'll have a 
64-bit time_t in every libc. :)

René



  reply	other threads:[~2017-03-01  1:36 UTC|newest]

Thread overview: 113+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27 21:30 [PATCH 0/6] Use time_t Johannes Schindelin
2017-02-27 21:30 ` [PATCH 1/6] t0006 & t5000: prepare for 64-bit time_t Johannes Schindelin
2017-02-27 22:55   ` Junio C Hamano
2017-02-27 21:30 ` [PATCH 2/6] Specify explicitly where we parse timestamps Johannes Schindelin
2017-02-27 22:37   ` Junio C Hamano
2017-02-27 22:51     ` Junio C Hamano
2017-02-28 10:49       ` Johannes Schindelin
2017-02-27 21:31 ` [PATCH 3/6] Introduce a new "printf format" for timestamps Johannes Schindelin
2017-03-01 18:20   ` Junio C Hamano
2017-03-01 19:53     ` Junio C Hamano
2017-02-27 21:31 ` [PATCH 4/6] Prepare for timestamps to use 64-bit signed types Johannes Schindelin
2017-02-27 21:31 ` [PATCH 5/6] ref-filter: avoid using `unsigned long` for catch-all data type Johannes Schindelin
2017-02-27 21:31 ` [PATCH 6/6] Use time_t where appropriate Johannes Schindelin
2017-02-27 22:48 ` [PATCH 0/6] Use time_t Junio C Hamano
2017-02-28 11:32   ` Johannes Schindelin
2017-02-28 14:28 ` Jeff King
2017-02-28 15:01   ` Johannes Schindelin
2017-02-28 16:38   ` René Scharfe
2017-02-28 18:55     ` Junio C Hamano
2017-02-28 20:04       ` Jeff King
2017-02-28 20:54       ` Johannes Schindelin
2017-02-28 21:31         ` Jeff King
2017-02-28 21:31         ` René Scharfe
2017-02-28 23:10           ` Johannes Schindelin
2017-03-01  0:59             ` René Scharfe [this message]
2017-02-28 17:26   ` Junio C Hamano
2017-02-28 20:01     ` Jeff King
2017-02-28 22:27       ` Junio C Hamano
2017-02-28 22:33         ` Jeff King
2017-03-01 17:23           ` Junio C Hamano
2017-04-02 19:06 ` [PATCH v2 0/8] Introduce timestamp_t for timestamps Johannes Schindelin
2017-04-02 19:06   ` [PATCH v2 1/8] ref-filter: avoid using `unsigned long` for catch-all data type Johannes Schindelin
2017-04-03  4:22     ` Torsten Bögershausen
2017-04-03 22:47       ` Johannes Schindelin
2017-04-02 19:06   ` [PATCH v2 2/8] t0006 & t5000: prepare for 64-bit timestamps Johannes Schindelin
2017-04-02 19:06   ` [PATCH v2 3/8] t0006 & t5000: skip "far in the future" test when time_t is too limited Johannes Schindelin
2017-04-02 19:06   ` [PATCH v2 4/8] Specify explicitly where we parse timestamps Johannes Schindelin
2017-04-03  4:26     ` Torsten Bögershausen
2017-04-03 22:50       ` Johannes Schindelin
2017-04-02 19:06   ` [PATCH v2 5/8] Introduce a new "printf format" for timestamps Johannes Schindelin
2017-04-02 19:06   ` [PATCH v2 6/8] Introduce a new data type " Johannes Schindelin
2017-04-02 19:07   ` [PATCH v2 7/8] Abort if the system time cannot handle one of our timestamps Johannes Schindelin
2017-04-02 19:07   ` [PATCH v2 8/8] Use uintmax_t for timestamps Johannes Schindelin
2017-04-20 20:52   ` [PATCH v3 0/8] Introduce timestamp_t " Johannes Schindelin
2017-04-20 20:52     ` [PATCH v3 1/8] ref-filter: avoid using `unsigned long` for catch-all data type Johannes Schindelin
2017-04-20 20:52     ` [PATCH v3 2/8] t0006 & t5000: prepare for 64-bit timestamps Johannes Schindelin
2017-04-20 20:58     ` [PATCH v3 3/8] t0006 & t5000: skip "far in the future" test when time_t is too limited Johannes Schindelin
2017-04-20 20:58     ` [PATCH v3 4/8] Specify explicitly where we parse timestamps Johannes Schindelin
2017-04-20 20:58     ` [PATCH v3 5/8] Introduce a new "printf format" for timestamps Johannes Schindelin
2017-04-20 20:58     ` [PATCH v3 6/8] Introduce a new data type " Johannes Schindelin
2017-04-20 20:58     ` [PATCH v3 7/8] Abort if the system time cannot handle one of our timestamps Johannes Schindelin
2017-04-20 20:59     ` [PATCH v3 8/8] Use uintmax_t for timestamps Johannes Schindelin
2017-04-21  6:05     ` [PATCH v3 0/8] Introduce timestamp_t " Junio C Hamano
2017-04-21 10:44       ` Johannes Schindelin
2017-04-21 10:45     ` [PATCH v4 0/9] " Johannes Schindelin
2017-04-21 10:45       ` [PATCH v4 1/9] ref-filter: avoid using `unsigned long` for catch-all data type Johannes Schindelin
2017-04-21 10:45       ` [PATCH v4 2/9] t0006 & t5000: prepare for 64-bit timestamps Johannes Schindelin
2017-04-21 10:45       ` [PATCH v4 3/9] t0006 & t5000: skip "far in the future" test when time_t is too limited Johannes Schindelin
2017-04-21 10:45       ` [PATCH v4 4/9] Specify explicitly where we parse timestamps Johannes Schindelin
2017-04-24  3:19         ` Junio C Hamano
2017-04-21 10:45       ` [PATCH v4 5/9] Introduce a new "printf format" for timestamps Johannes Schindelin
2017-04-21 10:45       ` [PATCH v4 6/9] Introduce a new data type " Johannes Schindelin
2017-04-21 10:45       ` [PATCH v4 7/9] Abort if the system time cannot handle one of our timestamps Johannes Schindelin
2017-04-24  3:16         ` Junio C Hamano
2017-04-24 13:57           ` Johannes Schindelin
2017-04-25  2:37             ` Junio C Hamano
2017-04-25  3:56             ` Junio C Hamano
2017-04-21 10:46       ` [PATCH v4 8/9] Use uintmax_t for timestamps Johannes Schindelin
2017-04-24  3:24         ` Junio C Hamano
2017-04-24 10:28           ` Johannes Schindelin
2017-04-25  3:59             ` Junio C Hamano
2017-04-25 20:10               ` Johannes Schindelin
2017-04-26  1:52                 ` Junio C Hamano
2017-04-26  3:45                   ` Junio C Hamano
2017-04-26  9:32                   ` Johannes Schindelin
2017-04-26 13:18                     ` Junio C Hamano
2017-04-21 10:46       ` [PATCH v4 9/9] show_date_ident(): defer date overflow check Johannes Schindelin
2017-04-24  3:29       ` [PATCH v4 0/9] Introduce timestamp_t for timestamps Junio C Hamano
2017-04-24  6:15         ` Jacob Keller
2017-04-24 14:02           ` Johannes Schindelin
2017-04-24 11:37         ` Jeff King
2017-04-25 20:13           ` Johannes Schindelin
2017-04-24 14:00         ` Johannes Schindelin
2017-04-24 13:57       ` [PATCH v5 0/8] " Johannes Schindelin
2017-04-24 13:57         ` [PATCH v5 1/8] ref-filter: avoid using `unsigned long` for catch-all data type Johannes Schindelin
2017-04-24 13:57         ` [PATCH v5 2/8] t0006 & t5000: prepare for 64-bit timestamps Johannes Schindelin
2017-04-24 13:58         ` [PATCH v5 3/8] t0006 & t5000: skip "far in the future" test when time_t is too limited Johannes Schindelin
2017-04-24 13:58         ` [PATCH v5 4/8] Specify explicitly where we parse timestamps Johannes Schindelin
2017-04-25  5:59           ` Junio C Hamano
2017-04-24 13:58         ` [PATCH v5 5/8] Introduce a new "printf format" for timestamps Johannes Schindelin
2017-04-24 13:58         ` [PATCH v5 6/8] Introduce a new data type " Johannes Schindelin
2017-04-26 16:43           ` Johannes Sixt
2017-04-26 19:18             ` Johannes Schindelin
2017-04-26 22:32           ` René Scharfe
2017-04-24 13:58         ` [PATCH v5 7/8] Abort if the system time cannot handle one of our timestamps Johannes Schindelin
2017-04-24 13:58         ` [PATCH v5 8/8] Use uintmax_t for timestamps Johannes Schindelin
2017-04-26 16:36           ` Johannes Sixt
2017-04-26 19:09             ` Johannes Schindelin
2017-04-25 21:54         ` [PATCH v5 0/8] Introduce timestamp_t " René Scharfe
2017-04-25 22:22           ` Johannes Schindelin
2017-04-26 22:09             ` René Scharfe
2017-04-26  1:56           ` Junio C Hamano
2017-04-26 19:20         ` [PATCH v6 " Johannes Schindelin
2017-04-26 19:26           ` [PATCH v6 1/8] ref-filter: avoid using `unsigned long` for catch-all data type Johannes Schindelin
2017-04-26 19:26           ` [PATCH v6 2/8] t0006 & t5000: prepare for 64-bit timestamps Johannes Schindelin
2017-04-26 19:26           ` [PATCH v6 3/8] t0006 & t5000: skip "far in the future" test when time_t is too limited Johannes Schindelin
2017-04-26 19:26           ` [PATCH v6 4/8] Specify explicitly where we parse timestamps Johannes Schindelin
2017-04-26 19:29           ` [PATCH v6 5/8] Introduce a new "printf format" for timestamps Johannes Schindelin
2017-04-26 19:29           ` [PATCH v6 6/8] Introduce a new data type " Johannes Schindelin
2017-05-20  5:47             ` [PATCH] name-rev: change a "long" variable to timestamp_t Junio C Hamano
2017-05-22 13:39               ` Johannes Schindelin
2017-04-26 19:29           ` [PATCH v6 7/8] Abort if the system time cannot handle one of our timestamps Johannes Schindelin
2017-04-26 19:29           ` [PATCH v6 8/8] Use uintmax_t for timestamps Johannes Schindelin

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=876bb673-ae8c-64bb-6a4d-385c84fb22d3@web.de \
    --to=l.s.r@web.de \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.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).