From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e36545482e8e19b4 X-Google-Attributes: gid103376,public From: mgk25@cl.cam.ac.uk (Markus Kuhn) Subject: Re: UNIX/POSIX Time Date: 1998/10/21 Message-ID: <70k3fm$n5s$1@pegasus.csx.cam.ac.uk>#1/1 X-Deja-AN: 403474637 References: Organization: U of Cambridge Computer Lab, UK Newsgroups: comp.lang.ada Date: 1998-10-21T00:00:00+00:00 List-Id: dale@cs.rmit.edu.au (Dale Stanbrough) writes: |> My guess? It will be too costly to replace 32 bit time_t, so a 64 bit |> time_t (time_t_64?) will be introduced along side it, and lots of code |> will continue to use time_t (32). C's time.h is broken in a great number of ways (there have already been many complaints about this during the ISO C89 standardization process), and there are currently several proposals around to replace it completely in ISO C 9X. Mine is on http://www.cl.cam.ac.uk/~mgk25/c-time/ including references to other proposals. Have a look at it (especially the rationale) if you are interested in problems there are and how they could be fixed nicely. I think my proposal contains numerous ideas that should also be of interest for the time API designers of other languages. Ada.Calendar is certainly better than time.h, but far from perfect and lacks for instance support for UTC leap seconds and local time zones. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: