From: janis_papanagnou+ng@hotmail.com   
      
   On 2026-01-05 23:41, Keith Thompson wrote:   
   > James Kuyper  writes:   
   >> On 2026-01-05 11:34, David Brown wrote:   
   >> ...   
   >>> As I understand it, time_t is intended to be suitable for holding a   
   >>> number of seconds ...   
   >>   
   >> The standard says nothing about that.   
   >>   
   >>> ... (it is used for that purpose in struct timespec). ...   
   >>   
   >> The standard says nothing to connect time_t to struct timespec.   
   >   
   > Yes, but also no.   
   >   
   > struct timespec contains at least the following members, in any order:   
   >   
   >      time_t tv_sec;  // whole seconds — ≥ 0   
   >      long   tv_nsec; // nanoseconds — [0, 999999999]   
   >   
   > But a footnote says:   
   >   
   >      The tv_sec member is a linear count of seconds and may not have   
   >      the normal semantics of a time_t.   
   >   
   > This makes for a simpler implementation *if* the time_t value   
   > returned by time(), and operated on by difftime(), mktime(), ctime(),   
   > gmtime(), and localtime(), happens to hold a linear count of seconds   
   > (as it does on most systems).   
      
   Hmm.. - my post is not aiming in your direction but this statement   
   made me curious. - A linear count (in the sense of TAI) should then   
   show a difference between civil time and [TAI-]seconds since Epoch.   
      
   A quick test shows that there's no leap seconds considered. So no   
   "linear count" (in the sense of TAI). Leap seconds are disregarded   
   in the "linear" seconds count.   
      
   >   
   > It's odd that time_t is used for two potentially very different   
   > purposes, one as a member of struct timespec and another as used   
   > in all other contexts.   
      
   Semantically it might have made sense if its used for differentiating   
   internal TAI (time_t) from UTC or local time on the UI (struct tm).   
      
   Janis   
      
   > And I would guess that a lot of code that   
   > uses struct timespec *assumes* that its time_t member has the same   
   > semantics value returned by time(NULL).   
   >   
   > For example, as I write this the time is 2026-01-05 22:32:57.881 UTC.   
   > The corresponding value returned by time() is 1767652377 (seconds   
   > since the 1970 epoch, no milliseconds).  An implementation could   
   > represent the current time (the value returned by time(NULL) as a   
   > 64-bit integer with the value 20260105223257881.  But timespec_get()   
   > would still have to set the tv_sec member to 1767652377.   
   >   
   > It might have been cleaner either to require that time_t represents a   
   > count of seconds, or to use a type other than time_t for the tv_sec   
   > member of struct timespec.   
   >   
   > I know there are systems that use something other than seconds   
   > since 1970 in the underlying time representation, but are there any   
   > C implementations that don't use seconds since 1970?  (POSIX and   
   > Windows both specify that.)   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)