Re: Unification of common date/time macros

[Alan Barrett <apb%cequrux.com@localhost>]

On Mon, 22 Sep 2014, Robert Elz wrote:
>  | My proposition is [...]
>  |
>  | #define SECSPERMIN      60L
>  | #define MINSPERHOUR     60L
>  | #define HOURSPERDAY     24L
>  | #define DAYSPERWEEK     7L
>  | #define DAYSPERNYEAR    365L
>  | #define DAYSPERLYEAR    366L
>  | #define SECSPERHOUR     (SECSPERMIN * MINSPERHOUR)
>  | #define SECSPERDAY      (SECSPERHOUR * HOURSPERDAY)
>  | #define MONSPERYEAR     12L
>  | #define EPOCH_YEAR      1970L
>
> Why are they all to be long ? The only one that has even the 
> slightest potential for that need (and which is currently 
> defined as long for the userspace definitions) is SECSPERDAY, 
> and that's only to cope with the possibility that int is 16 bits 
> (which I don't think NetBSD supports at all, since there is no 
> pdp11 port - but is kept that way for API consistency.)

kre's analysis is correct.  I'd just define them all as plain 
numbers, without any "L", "U", or "UL" suffix.  I'd probably 
also use 3600 and 86400 for SECSPERHOUR and SECSPERDAY, to avoid 
surprises in the arithmetic.

For an example of an unwanted surprise, consider (SECSPERHOUR 
* HOURSPERDAY) or ((60 * 60) * 24) on a machine with 16-bit 
ints: the desired result of 86400 is too large to represent in 16 
bits, which causes undefined behaviour.  NetBSD doesn't support 
any machines with 16-bit int, but this is the sort of code where 
it's easy to accommodate such machines, so we might as well do it.

--apb (Alan Barrett)