home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 242,798 of 243,242   
   David Brown to Lew Pitcher   
   Re: printf and time_t   
   05 Jan 26 17:34:14   
   
   From: david.brown@hesbynett.no   
      
   On 05/01/2026 17:23, Lew Pitcher wrote:   
   > On Mon, 05 Jan 2026 10:51:38 +0200, Michael S wrote:   
   >   
   >> On Mon, 5 Jan 2026 00:17:07 -0800   
   >> Andrey Tarasevich  wrote:   
   >>   
   >>> On Sun 1/4/2026 11:19 PM, Kenny McCormack wrote:   
   >>>> The question is: How can you reliably printf() a time_t value?   
   >>>> What conversion spec should you use?   
   >>>   
   >>> You can't. As far as the language is concerned, `time_t` is intended   
   >>> to be an opaque type. It has to be a real type, so it is either an   
   >>> integer of a plain floating-point type. But other than that nothing   
   >>> is known about it. There's really no point in printing it.   
   >>>   
   >>> If you still want to, you can do it in some implementation-specific   
   >>> way. Which still immediately means that you can't do it "reliably",   
   >>> if I understand what you mean correctly.   
   >>>   
   >>   
   >> I can't think about situation in which casting time_t value to 'long   
   >> long' can go wrong.   
   >   
   > As Andrey pointed out, time_t can resolve to a floatingpoint type,   
   > so, "long long" would go wrong if the implementation typedefs it to   
   >   float, or   
   >   double, or   
   >   long double.   
   >   
      
   As I understand it, time_t is intended to be suitable for holding a   
   number of seconds (it is used for that purpose in struct timespec).  So   
   while it might be a floating point type, it is unlikely to be holding a   
   value greater than 2 ** 63 (21 times the age of the universe in   
   seconds).  But I think there is still a hypothetical possibility that   
   the time_t value returned by, say, the "time" function, could have a   
   different scaling.  If that were scaled in nanoseconds, you could   
   overflow long long after only about 292 years.   
      
   Perhaps you are safer converting to _BitInt(128) :-)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca