Windows 32Bit Time/Date Format

Submitted by Trickkiste on Mon, 01/12/2009 - 16:48.

the general format of windows 32bit time/date is described at
http://msdn.microsoft.com/en-us/library/9kkf9tah.aspx

Inside JNode there are at least three different conversion algorithms implemented (dosTime & dosDate to Java friendly style):

from org.jnode.fs.jfat.FatUtils

int milliseconds = 0;
int seconds = (dosTime & 0x1f) * 2 ;
int minutes = (dosTime >> 5) & 0x3f;
int hours = dosTime >> 11;

int days = dosDate & 0x1f;
int months = ((dosDate >> 5) & 0x0f);
int years = 1980 + (dosDate >> 9);

from org.jnode.fs.util.DosUtils

cal.set(Calendar.MILLISECOND, 0);
cal.set(Calendar.SECOND, (dosTime & 0x1f) * 2);
cal.set(Calendar.MINUTE, (dosTime >> 5) & 0x3f);
cal.set(Calendar.HOUR_OF_DAY, dosTime >> 11);

cal.set(Calendar.DATE, dosDate & 0x1f);
cal.set(Calendar.MONTH, ((dosDate >> 5) & 0x0f) - 1);
cal.set(Calendar.YEAR, 1980 + (dosDate >> 9));

from java.util.zip.ZipEntry (classpath)
(dostime as int includes short dosTime and short dosDate)

int sec = 2 * (dostime & 0x1f);
int min = (dostime >> 5) & 0x3f;
int hrs = (dostime >> 11) & 0x1f;

int day = (dostime >> 16) & 0x1f;
int mon = ((dostime >> 21) & 0xf) - 1;
int year = ((dostime >> 25) & 0x7f) + 1980; /* since 1900 */

From my point of view the last one is appropriate, can someone confirm that?

I added the last one to the JIFSJarFile, so the jar files at /jifs/lib have the last modified date correctly displayed from the Zip-File-Descriptor.

Andreas

‹ Mounting EXT2 or FAT32? Proposal for a better source organization ›

Let's remove the second version

Submitted by Peter on Sat, 01/24/2009 - 23:54.

I see it similar to you. Though imho the first version is quite the same as the third version except that in the first version dostime was split in dosTime and dosDate before evaluating the single values.
For the month variable it depends on the use case. I guess there are cases where you start to count months from 0-11 and others 1-12. So the decision if you decrement "mon" or not depends on what you need.

The second version (i.e. the one in DosUtils) is really bad. The method returns a "long", so the use of Calendar is total overhead. I'm mentioning that, as we noticed a while back that Calendar (locale dependant) is accessing the filesystem. This produced a stackoverflow as access to the filesystem needed Calendar (this happened in jfat).