On 05/31/17 10:30 AM, Richard L. Hamilton wrote:
On May 31, 2017, at 13:01, Alan Coopersmith <alan.coopersm...@oracle.com> wrote:
On 05/31/17 09:43 AM, Richard L. Hamilton wrote:
The alternative would be a large times analog of large file support; why that
wasn't done when 64-bit began, I don't understand. :-)
It was considered at Sun in the late 90's but discarded as going full LP64
already provided a solution without combinatorial explosion of test matrices
for large files x large times. The large files API was created before LP64
was an option on most Unixes, including Solaris.
Testing, yes; that makes sense.
How are the time conversion functions doing with regard to time_t past
INT32_MAX? I see that (with a 64-bit executable) at least ctime() seems to
work enough beyond for usual life and commercial purposes (aside from
radioactive waste :-) ):
13:15:32[13]monster:/home/rlhamil> ./maxtime
time overflow after Tue Jan 19 03:14:07 2038
in 32-bit signed two's complement
timestamp 9223372036854775807 (INT64_MAX) cannot be processed by ctime()
t=2147483647: Tue Jan 19 03:14:07 2038
t=4294967294: Sun Feb 7 06:28:14 2106
t=8589934588: Wed Mar 16 12:56:28 2242
t=17179869176: Wed May 30 01:52:56 2514
t=34359738352: Tue Oct 26 03:45:52 3058
t=68719476704: Sun Aug 20 07:31:44 4147
t=137438953408: Wed Apr 8 15:03:28 6325
t=274877906816: (null)
On Solaris, ctime() is defined as returning a string of exactly 26 characters,
so it gives up when the year requires a 5th digit and doesn't fit.
Converting to strftime and compiling with -std=c99 -m64 -D_XOPEN_SOURCE=700
gets a bit further here:
for (t=INT32_MAX;t<=INT64_MAX && t>=0L;t<<=1) {
char s[100] = "";
struct tm *l = localtime(&t);
if (l != NULL)
strftime(s, sizeof(s), "%a %b %e %H:%M:%S %Y", l);
else
snprintf(s, sizeof(s), "localtime(%ld) == NULL", t);
printf("t=%ld: %s\n", t, s);
}
time overflow after Tue Jan 19 03:14:07 2038
in 32-bit signed two's complement
timestamp 9223372036854775807 (INT64_MAX) cannot be processed by ctime()
t=2147483647: Tue Jan 19 03:14:07 2038
t=4294967294: Sun Feb 7 06:28:14 2106
t=8589934588: Wed Mar 16 12:56:28 2242
t=17179869176: Wed May 30 01:52:56 2514
t=34359738352: Tue Oct 26 03:45:52 3058
t=68719476704: Sun Aug 20 07:31:44 4147
t=137438953408: Wed Apr 8 15:03:28 6325
t=274877906816: Wed Jul 14 06:06:56 10680
t=549755813632: Tue Jan 25 12:13:52 19391
t=1099511627264: Mon Feb 20 00:27:44 36812
t=2199023254528: Fri Apr 10 00:55:28 71654
t=4398046509056: Sat Jul 19 01:50:56 141338
t=8796093018112: Mon Feb 4 03:41:52 280707
t=17592186036224: Fri Mar 8 07:23:44 559444
t=35184372072448: Sat May 14 14:47:28 1116918
t=70368744144896: Tue Sep 25 05:34:56 2231866
t=140737488289792: Sun Jun 19 11:09:52 4461763
t=281474976579584: Wed Dec 5 22:19:44 8921556
t=562949953159168: Wed Nov 10 20:39:28 17841143
t=1125899906318336: Wed Sep 19 17:18:56 35680317
t=2251799812636672: Wed Jun 7 10:37:52 71358665
t=4503599625273344: Tue Nov 11 21:15:44 142715360
t=9007199250546688: Mon Sep 24 18:31:28 285428751
t=18014398501093376: Sat Jun 17 13:02:56 570855533
t=36028797002186752: Tue Dec 1 02:05:52 1141709096
t=72057594004373504: localtime(72057594004373504) == NULL
t=144115188008747008: localtime(144115188008747008) == NULL
t=288230376017494016: localtime(288230376017494016) == NULL
t=576460752034988032: localtime(576460752034988032) == NULL
t=1152921504069976064: localtime(1152921504069976064) == NULL
t=2305843008139952128: localtime(2305843008139952128) == NULL
t=4611686016279904256: localtime(4611686016279904256) == NULL
t=9223372032559808512: localtime(9223372032559808512) == NULL
I suggest anyone working with such precise timestamps more than a billion years
in the future use a system more oriented towards such scientific calculations
than the C standard library. I'm sure it's timezone code does not account for
the changes in the Earth's rotation nor the tectonic plate migration that will
have occurred over that timespan.
-alan-
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
