> Currently modification dates are stored and returned to the user as > PRInt64 . When this value is passed into javascript, there is data > loss: it is truncation to a 48 bit double. Is this really what is > happening: we are jamming a 64 bit number into the space of a 64 bit > number? doubles are 52 bits mantissa, 11 bits exponent, 1 bit sign of mantissa, IIRC. But you're right, we lose precision when given too many bits of integral type. > This observed loss is causing problems when trying to compare files via > a timestamp. To fix this problem, I am thinking about rounding the > modifications dates returned via |lastModificationDate| and > |lastModificationDateOfLink|. Instead of returning microseconds, > nsIFile would return milliseconds - or - maybe some quanity of > microseconds. Just use milliseconds, like Java and JS. JS Date uses milliseconds too and fits 'em in a double.

Since I wrote the unquoted (no leading "> " on each line) words above, I'm setting M16 TM! /be

fix checked in. Please verify that timestamps still work in xpinstall.

Build: 2000-05-10-09-M16(LINUX), 2000-05-10-09-M16(WIN), 2000-05-10-08-M16(MAC) For Macintosh, all files are getting a time stamp of Jan 1, 1970 12:15 AM. Running the installer and checking all the installed files is an easy way to see this. For Windows, all files appear to be getting the current date and time instead of retaining the original date and time of the file(s). For Linux, I'm not 100% sure what is right and wrong. But I have a test case following to prove that it's not alright (this test can be used for all platforms). 1. From http://jimbob/trigger3.html, click Acceptance drop-down and choose a_adddelfile (it should be the default test case showing) and click the Trigger case button 2. Click the itty, bitty Ok button from the confirmation dialog RESULT: From the "Program" folder, change to the subdirectory, delregfile, and check the date stamp on the file, deletecomponent.txt. From Linux, the date stamp shows Jan 11, 1970. From Macintosh, the date stamp shows Jan 1, 1970, 12:15 am. From Windows, the date stamp shows the current date and time of installation. EXPECTED RESULT: The file, deletecomponent.txt, should have a date stamp of 4/16/99 4:28 pm.

using xpinstall was a bad test case: it was horked in libjar. This bug is fixed. To verify, you should use xpcshell to inspect the return value from nsIFile. Note that it is in usec's.

I should have said millisecond, not usec. It will return up to one thousandth of a second resolution.

Build: 2000-05-18-09-M16(WIN), 2000-05-18-08-M16(LINUX) The XPInstall tests are passing for Windows and Linux. Macintosh is blocked by Bug 38989.

I'm reopening this bug because the current time stamp stuff in nsIFile is really confusing and it's realyl in need of some cleaning up. First of all, all time calculations in mozilla should be done through nspr to be and remain XP, right? Well, nspr defines PRTime as PRInt64, and thus since nsIFile::{G,S}etLastModificationDate() gets and sets the time using PRInt64 people (and existing code) assume the time they get from nsIFile is PRTime. PRTime is defined as microseconds (usecs) since midnight January 1, 1970. Also, the comment in nsIFile.{idl,h} about lastModificationDate says the time returned is in "...Milliseconds (usecs)...", usecs should be msecs, right?. Now, to make the definition of nsIFile::lastModificationDate more obvious from reading the idl/header I think either the returned time should be changed back to be microseconds since the epoch, or the retuned time should remain milliseconds from the epoch but the return type should be PRInt32, and not PRInt64, to match the type normally used to represent milliseconds from the epoch. (when this change was checked in, bug 36681 regressed.)

I caught dougt's usec for msec in a news posting, but didn't check the .idl file. Thanks. We can't use usec because JS maps PRInt64 into double, which has only 52 bits of mantissa. We must use milliseconds, which are more than fine-grained enough for the forseeable future. But we can't use PRInt32 to hold msec since the epoch: there are 8.64e4 seconds in a day. A year makes that > 3e7. Msec > 3e10 and we have overflowed even an unsigned 32-bit integer. This difference from NSPR needs to be documented, but I think nsIFile is right to use msec rather than the too-fine usec of NSPR (which goes back to something kipp did in 1995, after I'd hacked up prlong.h so we could use int64s portably; but why he didn't match Java, which even then used msec not usec, I don't remember). /be

modified the comment.

Build: 2000-05-26-08-M16(MAC), 2000-05-26-09-M16(WIN), 2000-05-26-08-M16(LINUX) For the XPInstall part, both Windows and Linux behave as expected. Macintosh is still showing the incorrect date, Jan. 11, 1970 4:44 PM. We are still expecting Apr. 16, 1999 4:28 PM. I am only familiar with XPInstall, so I am not verifying any other part of the implementation. Ccing Dan to keep him in the loop. Reopening bug since Mac is still failing. Doug is on paternity leave, so I can use some help with getting this reassigned. Thanks.

The bug was in fact that Doug was attempting to return in microseconds when he mentions above that he "fixed" it to return in milliseconds. This was deep in the nsLocalFileMac implementation and has now been fixed to coincide with the originally suggested fix: return millisecs. This fix was actually for bug #31259, which is used by XPInstall as the client of nsIFile -- a *valid* testcase. This fix also happens to fix bug #42070. marking this bug fixed for what Jimmy is complaining about.

Build: 2000-06-12-14-M17(MAC) Mac is fixed now.