On Tue, Jul 12, 2016 at 8:16 AM, Jeff King <peff@xxxxxxxx> wrote: >> >> But moving the internal time representation used in various fields >> like commit->date to time_t is likely to be a wrong thing to do, >> because the first problem with "unsigned long", i.e. "may not be >> wide enough", is not limited to "not wide enough to hold time_t". >> It also includes "it may not be wide enough to hold time somebody >> else recorded in existing objects". > > But that's a problem no matter what size we choose. Yes, if somebody's time_t is larger than my intmax_t, the problem cannot be solved for me, if that timestamp is too far in the future or in the past. But that is not the problem I am pointing out. I heard earlier in the thread that time_t on one system was 32-bit (was it Linux?) but I think they have "long long". Choosing time_t is strictly inferior choice when we already know that a platform with not-wide-enough time_t need to be supported, and a type that is wider than that is available. I was envisioning that we would have typedef <sometime> gittime_t with conversion helpers between it and time_t that allow us to do some range checks while at it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html