OS X tracks nanosecond modification times in the file system, but there are defines in the system headers to expose the standard st_mtime, etc. members.
When building 64-bit time_t is 64-bit, not 32-bit... Sent from my iPhone On Jun 17, 2012, at 1:59 PM, Ian MacArthur <[email protected]> wrote: > > On 16 Jun 2012, at 23:48, Matthias Melcher wrote: > >> On 16.06.2012, at 22:58, Ian MacArthur wrote: >> >>> On 16 Jun 2012, at 00:10, Matthias Melcher wrote: >>>> >>>> OK, I think I have Connect pretty stable. I will implement HTTP GET in the >>>> next days and then fix FTP (I may remove the file date stuff...). Comments >>>> and suggestions are welcome ;-) >>> >>> (Without actually writing any code to use...) I had imagined we could do >>> the time / date stuff just by reverting to some sort of "lowest common >>> denominator" (e.g. time_t perhaps) and convert the OSX stat values to that >>> format internally... And then it would all "just work" and ... >>> >>> Well. I don't know really... >> >> Yes, sounds like a good idea. I think that Apple used a struct instead of >> time_t to avoid running into some y2k issue. Not sure when time_t will wrap?! > > Ah, well that depends on what size you think time_t is... If it is a signed > 32-bit int, then sometime in 2038. If it's 64-bit, well, then we are not so > worried I guess! (Approx. 292 Billion years, in case anyone was wondering...) > > > > > > > > _______________________________________________ > fltk-dev mailing list > [email protected] > http://lists.easysw.com/mailman/listinfo/fltk-dev _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
