From shadow@krypton.rain.com Thu Dec 05 10:49:40 1996 Path: news.ibi.co.za!news1.saix.net!uunet!in1.uu.net!205.252.116.190!feed1.news.erols.com!howland.erols.net!swrinde!ihnp4.ucsd.edu!info.ucla.edu!nnrp.info.ucla.edu!psgrain!qiclab.scn.rain.com!krypton!shadow From: shadow@krypton.rain.com (Leonard Erickson) Newsgroups: comp.software.year-2000 Subject: Re: Y2K: Cinderella - DIR, LIST, ZIP, BACKUP with MSDOS - Topic 002 Message-ID: <961205.004940.1t3.rnr.w165w@krypton.rain.com> Date: Thu, 5 Dec 1996 00:49:40 PST References: <329e9780.228872@news.fast.co.za> Organization: Shadownet X-Newsreader: rnr v2.20 Lines: 59 slug@fast.co.za (slug) writes: > Y2K: Cinderella - DIR, LIST, ZIP, BACKUP with MSDOS - Topic > 002 > > CATEGORY: basic file functions, directory display, > file backup and restore. > Standard supplied functionality. > > SUMMARY: > > The critical feature of interest in MS DOS is the file > management system. Directory structures use Binary > dates. The date can be set between 1980 and 2099. > > Thus, if the correct current date is set, the correct > date will be written to the directory. > Provided comparisons are done on this binary date, > all is well. > > Display of the date (or reading of the date within a > program) are the areas where problems arise. > > In general, handling of file dates within MSDOS is > acceptable. Due to the way date and time info is stored in MS-DOS directory entries, it is virtually certain that any program doing comparisons of file date/time stamps will not have Y2k problems. This is because the date and time are stored in a manner such that a sort on the *packed* (ie "raw") date/time fields will yeild the correct ordering. The data is stored as bit-fields inside a pair of 2-byte integers (which can also be treated as a single 4-byte integer): Date Time YYYYYYYM MMMDDDDD hhhhhmmm mmmsssss 76543210 76543210 76543210 76543210 Y = year (0-127) h = hour (0-23) M = month (1-12) m = minutes (0-59) D = day of month (1-31) s = seconds/2 (0-29) This doesn't mean that some stupid programmer couldn't have used the functions to retrieve the unpacked data and then misused it. But it *does* mean that anybody trying to optimize their code's handling of date comparisons will have switched to direct compares of the fields, which is both very fast, *and* (due to an intelligent design decision!) immune to Y2k problems! It is *possible* that some apps might break around 2044. That would be due to use of a *signed* integer for date compares. But given that there exist (or at least used to exist!) several widely distributed "freeware" utilities that had somehow acquired dates in the 2080s, I suspect that such bugs were found rather early on. -- Leonard Erickson (aka Shadow) shadow@krypton.rain.com <--preferred leonard@qiclab.scn.rain.com <--last resort