SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Apple Inc.
AAPL 272.24+0.5%Dec 23 3:59 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Jonathan Bird who wrote (8442)2/12/1998 8:57:00 PM
From: Russ  Read Replies (1) of 213177
 
Y2K on Macs

The internal time maintained by the system is based on seconds since antiquity, which I believe is Jan 1,1904 (Not sure of the date, but it was some weird year in the 1900's. UNIX sets its time from 1972, which is when UNIX was invented). The original Macs (128k, 512k, Plus, SE) can go up to 2006 or 2017 (forget which). The newer ones go up to something like 2295.

Whether or not a given piece of software is Y2K compliant depends on the person who wrote the software. If dates and times are stored via calls to the OS, it'll be fine. If they rolled their own, it may not be. I used to run a big accounting app on our Macs called Flexware. It was based on a port of an old VAX database. At the time I ran it (about 10 years ago) dates were stored in the db in Julian form w/ 5 digit numbers, so 1/1/84 was 84001, and 12/30/94 was 94364. That is definitely not Y2K compliant. (I assume they now use 7 digit Julian numbers for dates.)

So, your general purpose apps written for the Mac should be OK, but anything that uses a proprietary database may not be.

-Russ
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext