Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++,comp.lang.c Subject: Re: "C++: Size Matters in Platform Compatibility" Date: Sun, 18 Aug 2019 14:49:40 -0700 Organization: None to speak of Lines: 26 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="9783fc84761b29b85f300e9e166573f7"; logging-data="20076"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18lHL7q4vNfjKWsD2tM2Wwo" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:DAnwXO3cPIvcQOKI+7RYvHM2EN0= sha1:18rtWDYGjBfVp5pf5VfCkqlWrIc= Xref: csiph.com comp.lang.c++:67769 comp.lang.c:145720 Geoff writes: > On Sun, 18 Aug 2019 12:32:18 +0200, David Brown > wrote: > >>> The UNIX epoch-based 64-bit time is good only if you believe the sun >>> will only last another 2.147 billion years. >> >>292 billion years, by my counting. By that time, any issues with >>rollover will be an SEP¹. > > Where are you getting that? time_t is the number of seconds since > January 1, 1970, 0:00 UTC and as a 64-bit integer that's not 292 > billion years. Yes, it is. A signed 64-bit time_t has a maximum value of 2**63-1. 2**63-1 seconds is just over 292 billion years. The GNU coreutils "date" command gives an out of range error for dates past Dec 31 in the year 2147485547, but that's not a time_t issue. Similarly, the type struct tm has tm_year as an int, which imposes the same limit on systems where int is 32 bits. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */