[jcifs] timezone problems

[Julian Reschke]

Michael B Allen wrote:

> 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

Right.

> 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.

I think my tests show that at least the adjustment *attempted* by JCifs 
doesn't work correctly. As far as I can tell this has been reproduced 
for local shares on NT4, W2000 and W2003 systems.

> 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.

At the end of the day, we should be able to agree on reproducable test 
cases and their expected outcome. If the outcome is not what we expect, 
there's a bug. If the bug can be reproduced on a plain W2K installation, 
a current Sun Java VM, and JCifs (with no dependency on java.io.File 
itself), then I'd argue that it probably is a bug in JCifs.

I propose the following setup:

1) Use a non-Java, non-SMB tool to create two files with known lastmod 
dates,

2) Check that JCifs is reporting the correct ms-since-the-epoch for 
lastmodified.

Do we agree that this is a valid test scenario?

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760