Re: [tcljava-dev] Jacl and file mtime

[Christian K. <chr...@so...>]

Hello,

Christian Sorensen wrote:

> I am using the Java implementation of Tcl, called Jacl, version 1.2.6.

> I just tried to use the "file mtime <filename>" command and found out that
> it does not work properly (on Windows 95/NT, that is). The reason seems to
> be that the Tcl concept of integers is 32-bit and that the Java
> File.getModified() method returns a long too long to be stored in an int.
> By experimenting with  File.getModified() in pure Java (on Windows 95) I
> found out that the three rigtmost digits of this huge number always were
> "000". So, by fixing tcl.lang.FileCmd's method getMtime() to return the
> time / 1000, "file mtime" became acceptable for an int - and it became
> useful, e.g. for "make" like utilities.

The JavaDoc of File.lastModified() explicitely mentions, that the return value
should be interpreted in milliseconds. So I think that the implementation
of FileCmd.getMtime() is just wrong. It should devide the long value by 1000
any way to receive a valid date in seconds.

> What happens on non-Windows platforms I don't know.

I wonder why the comment in FileCmd.java above the definition of getMtime()
states that the return value of File.lastModified() is platform dependent.
This is not mentioned by the docs and at least on Linux and Windows the
return value is actually the same: the amount of millis since the Epoch.

I think the patch should devide by 1000 and should remove the comment also...
So it would read like the following:

---- FileCmd.java~       Wed Aug 16 06:45:36 2000
+++ FileCmd.java        Mon Jan  8 09:09:05 2001
@@ -462,9 +462,6 @@
  * getMtime --
  *
  *     Finds the last modification of file in fileObj.
- *     WARNING:   The return value of lastModified() is system dependent and
- *     should only be used to compare with other values returned by last
- *     modified. It should not be interpreted as an absolute time.
  *
  * Results:
  *     Returns an int representation of modification time.
@@ -488,7 +485,7 @@
        throw new TclPosixException(interp, TclPosixException.ENOENT, true,
                "could not read \"" + fileName + "\"");
     }
-    return (int) fileObj.lastModified();
+    return (int) (fileObj.lastModified() / 1000);
 }
 
 
 /*

> By the way: This "97" indicates that soon (?) we should be able to handle
> 13 digits!!?

Not exactly. The overrun will happen, but some thirty years ahead:
bash-2.04$ jaclsh
% expr 0x7fffffff
2147483647
% clock format 0x7fffffff
Tue Jan 19 04:14:07 GMT+01:00 2038

Greetings, Krischan
-- 
Christian Krone, SQL Datenbanksysteme GmbH