[jcifs] timezone problems

Michael B Allen mba2000 at ioplex.com
Thu Mar 11 04:00:24 GMT 2004


We're not going about this the right way. I'm a little short on time right
now but let's review what we know:

Java represents time internally is milliseconds since Jan 1, 1970 00:00 GMT.
The Date.toString() method returns a string adjusted to TZ and DST of the
local VM.
The Date.getTime() method returns milliseconds since Jan 1, 1970 00:00 GMT
The File.setLastModifed() operation takes milliseconds since Jan 1, 1970
00:00 GMT

Here's the relivant section from the "CIFS Technical Reference":

typedef struct {
    ULONG LowTime;
    LONG HighTime;
} TIME;

TIME indicates a signed 64-bit integer representing either an absolute
time or a time interval. Times are specified in units of 100ns. A positive
value expresses an absolute time. The time base (the 64-bit integer with
value 0) is the beginning of the year 1601 AD in the Gregorian calendar
UTC. However, file creation, modification and access times include an
additional correction factor as follows:

    Tf = Tutc + Tdaf - Tdan

Where
    Tf time reported for file creation/modification/deletion
    Tutc UTC time (secs since 1601 AD)
    Tdaf Daylight savings adjustment (positive quantity) in effect at Tf
    Tdan Current daylight savings adjustment (positive quantity)

For example, if a file is created in the summer - when daylight savings
time is in effect - the creation time will be reported as

    Summer: Tutc + 3600 - 3600 = Tutc
    Winter: Tutc + 3600 - 0 = Tutc + 3600

If a file is created during the winter - when daylight savings time not in
effect - the creation time will be reported as:

    Summer: Tutc + 0 - 3600 = Tutc - 3600
    Winter: Tutc + 0 - 0 = Tutc

A negative value expresses a time interval relative to some base time,
usually the current time.


I believe the above is from the prespective of the server so the client
will have to reverse the effect of the "correction factor" to get back to
UTC. It should also be considered that the above documentation could be
incorrect. Considering the history behind it I would not be surprised at
all.

Ultimately I think what we have is pretty close. It makes sense that we
use a TZ based on the server rather than the client (as I think Justin has
pointed out) but considering all of our tests have been on local servers I
don't think that's the source of the discrepency. In fact I'm still not
convinced we're doing anything wrong at all.

Comon' Chris, this is your bread and butter dude!

Mike


More information about the jcifs mailing list