Glenn Fowler <gsf at research.att.com> wrote:
>
> On Wed, 01 Nov 2006 15:40:49 +0100 Casper.Dik at Sun.COM wrote:
> > >32-bit objects have a long long type and handle 64 bit timestamps
> > >when compiled with LARGEFILE_SOURCE
>
> > Offsets, not timestamps, unfortunately.
>
> yes, thanks
> posix 64 bit timestamps are a struct of 2 32's and not one 64 bit integer
> the main point stands that 32/64 bit objects are independent of
> LARGEFILE_SOURCE
There is still a difference.
BSD UNIX did have 64 bit timestamps since 1981 but this was 32 bit
for seconds and 32 bits for microseconds. Solaris used 32 bits for seconds and
32 bits for nanoseconds.
Solaris later did introduce 64 bits for time_t for 64 bit programs.
> btw, the ast source handles <tv_sec,tv_nsec> resolution times by converting
> to 64 bit Time_t nanoseconds since the epoch, giving a max representable date
> of
> "2554-07-21+23:34:33.709551614 UTC", greatly simplifying ast time manipulation
> code
Could you explain please?
With a 64 bit time_t, you are able to represent 1970 +-292277256192 years.
The current UNIX time problem is struct tm that only allows 1900 +- 2G years.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
