home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.pascal
- Path: sparky!uunet!psgrain!qiclab!leonard
- From: leonard@qiclab.scn.rain.com (Leonard Erickson)
- Subject: Re: packtime and unpacktime algorithms?
- Message-ID: <1992Jul31.084159.18466@qiclab.scn.rain.com>
- Reply-To: 70465.203@compuserve.com
- Organization: SCN Research/Qic Laboratories of Tigard, Oregon.
- References: <31597@adm.brl.mil>
- Date: Fri, 31 Jul 1992 08:41:59 GMT
- Lines: 31
-
- STANKULI%UWF.BITNET@vtvm2.cc.vt.edu ( stan kulikowski ii) writes:
-
- > does anyone have access to tp's algorithms for packtime and unpacktime
- >procedures? the longint returned by packtime is not a standard julian
- >date so i would like to know what the limits in the numerical conversion
- >are. i assume this was established by microsoft somewhere when they set up
- >their FAT specifications.
-
- Split it into a pair of words. The first is the time, coded like this:
- time= (hour*2048) + (minutes*32) + (seconds div 2)
-
- the second is the date, coded as follows:
- date= ((year-1980)*512) + (month*32) + day
-
- >it seems a shame that the datetime type defined in the dos unit does not have
- >100th seconds in it so we could use the thing for elapsed time measurements
- >within the 10th second accuracy we can get from the clock.
-
- If you examine the above, you'll see that DateTime isn't good for better than
- 2 second accuracy anyway. If you are going to use "accurate" timing, declare
- a longint at the system timer count.
- TimerCount : longint absolute $0040:$006C;
-
- This gives you the full 18.2 Hz accuracy of the timer tick.
- (Just don't forget that it resets to 0 at midnite!)
-
- --
- Leonard Erickson leonard@qiclab.scn.rain.com
- CIS: [70465,203] 70465.203@compuserve.com
- FIDO: 1:105/56 Leonard.Erickson@f56.n105.z1.fidonet.org
- (The CIS address is checked daily. The others infrequently)
-