[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: EPOCHREALTIME does not behave correctly before 1970
From:       Chet Ramey <chet.ramey () case ! edu>
Date:       2021-08-23 0:24:38
Message-ID: 5bbf322a-0564-accb-6327-57c07a6fcdfb () case ! edu
[Download RAW message or body]

On 8/22/21 7:52 PM, Kerin Millar wrote:
> On Sun, 22 Aug 2021 16:13:28 -0400
> Chet Ramey <chet.ramey@case.edu> wrote:
> 
> > On 8/21/21 1:28 AM, Emanuele Torre wrote:
> > 
> > > Bash Version: 5.1
> > > Patch Level: 8
> > > Release Status: release
> > > 
> > 
> > > get_epochrealtime() casts tv.tv_sec (a time_t a.k.a. int) to unsigned
> > > int causing EPOCHREALTIME to not behave correctly before the Unix Epoch.
> > 
> > The definition is seconds since the Unix epoch. It's not surprising that it
> > doesn't pay attention to dates before that.
> 
> The problem with this statement is that EPOCHREALTIME is permitted to get it wrong, \
> yet EPOCHSECONDS is permitted to get it right. The discrepancy certainly came as a \
> surprise to me.

It's whatever the kernel tells you is ok. EPOCHSECONDS uses time();
EPOCHREALTIME uses gettimeofday(). Both are defined to return the time
in seonds (and, in the latter case, microseconds) since the epoch. You can
argue that bash should check whether the return value of seconds is < 0,
but that isn't one of the defined failure modes.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[prev in list] [next in list] [prev in thread] [next in thread]