bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gawk] gawk with dates before 1970


From: Nelson H. F. Beebe
Subject: Re: [bug-gawk] gawk with dates before 1970
Date: Tue, 14 Apr 2015 09:14:43 -0600 (MDT)

Arnold Robbins writes about the signedness of time_t:

>> This is not enough, you need also to make sure that the underlying
>> time functions can handle negative values.  That this is so on your
>> platform is in no way a sign that it's so everywhere else.
>>
>> At least one system that uses unsigned time_t is still supported,

I just checked my roughly 40 flavors of Unix (including *BSD,
GNU/Linux, Hurd, IRIX, Mac OS X, Minix, and Solaris on a variety of
CPUs), and TOPS-20 on DEC PDP-10, and found that all of them use a
signed 32-bit or 64-bit integer for time_t.

I then looked at the POSIX and ISO C and C++ Standards, and found that
they only require that time_t and clock_t be an arithmetic type
(either integer or floating-point), and make no statement about
whether those two types are signed or unsigned.

The flexibility provided by those standards suggests that it would be
unwise to make assumptions about the underlying datatype and
signedness of time_t and clock_t.

A Standard C function provides a partial solution for finding the
interval between time_t values:

        7.27.2.2 The difftime function
        Synopsis
1                  #include <time.h>
                   double difftime(time_t time1, time_t time0);

        Description
2       The difftime function computes the difference between two calendar
        times: time1 - time0.

        Returns
3       The difftime function returns the difference expressed in seconds as
        a double.
 
Because double on most systems (except for some older embedded
processors and older GPUs) is generally the IEEE 754 64-bit format, it
provides at least 53 bits of precision.  That may not be adequate if
time_t is a 64-bit type, because a difference of such numbers could
require rounding.  Once again, we have a subtle dependency on native
arithmetic and possible integer overflow (e.g., a 64-bit signed
integer would have a worst-case difference of (2**63 - 1) - (-2**63) =
2**64 - 1, a value that is outside the range of signed 64-bit
arithmetic, and would be interpreted as a negative number).


-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: address@hidden  -
- 155 S 1400 E RM 233                       address@hidden  address@hidden -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]