Newsgroups: comp.std.internat Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.iastate.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!msp33327 From: msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas) Subject: Re: What time is it? [Was: Data compression standard] Message-ID: <1991Jun24.231644.2020@ux1.cso.uiuc.edu> Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois at Urbana References: <859@spam.ua.oz> <3761@sirius.ucs.adelaide.edu.au> Date: Mon, 24 Jun 1991 23:16:44 GMT Lines: 20 In shores@fergvax.unl.edu (Shores) writes: >I have a better idea. Instead of storing a date STRING, why not just >store a number? The Macintosh stores dates as a 4 byte number, >representing the seconds elapsed since Jan 1, 1904. Unix has a similar >convention, only from 1972 (better, IMHO). Then it should be up to the >user program to represent the date. The Mac has IUDateString, unix and >others have ctime(), etc. That is totally non-human-readable, however. That may not matter for the application that started this thread, whatever that was, but it can be useful. Further, everyone will probably use a different scheme, and one 32 bit number looks the same as the next. Also, if you decide that you need tenth-second accuracy, the string can be extended without breaking the logic of the scheme, even if it does -- < Michael Pereckas <> m-pereckas@uiuc.edu <> Just another student... > "This desoldering braid doesn't work. What's this cheap stuff made of, anyway?" "I don't know, looks like solder to me."