[jcifs] timezone problems

Julian Reschke julian.reschke at gmx.de
Wed Mar 10 22:37:47 GMT 2004


Christopher R. Hertel wrote:

> On Wed, Mar 10, 2004 at 03:54:55PM +0100, Julian Reschke wrote:
> 
>>Michael B Allen wrote:
>>
>>>Julian Reschke said:
>>>
>>>Ok, I think I see what you're talking about. I tried your program on
>>>Windows NT 4.0 and I see the discrepency. Something is definately wrong
>>>but I don't think it has to do with jCIFS. It's either the Java VM on
>>>Linux or the Java VM on Windows.
>>
>>It's good that we agree that something is wrong. So let's try to find 
>>out what it is.
>>
>>I think we can rule out java.io.File, because checking the timestamps 
>>using Cygwin's date utility confirms that the timestamp was created 
>>correctly.
>>
>>Just to make sure, I'm also testing with standard Microsoft utilities:
>>
>>   var fso, f;
>>   fso = new ActiveXObject("Scripting.FileSystemObject");
>>   f = fso.GetFile(WScript.Arguments(0));
>>   WScript.Echo("created: " + f.DateCreated);
>>   WScript.Echo("mod: " + f.DateLastModified);
>>
>>and they confirm that the timestamps are correct.
> 
> 
> Wait...
> 
> If all the other tools give the correct timestamp, but java.io.File gives 
> the *wrong* timestamp, then...
> 
> I'm sure I'm not understanding you correctly here.

Everybody agrees on the timestamps, except for JCifs (with JCifs running 
on W2K serving the files).

> I think it's a fancy way of saying that the file timestamps are in machine 
> local time *at the time the timestamp was created*.  In other words, the 
> file timestamps are created based on clock time, not UTC.
> 
> The problem (if my guess is correct) is that there is NO indication of DST
> usage.  The timestamp says "three o'clock PM" and there's no good way of
> knowing for sure whether that's x hours off of UTC or x+1 hours off of
> UTC.  The 'bad' way of knowing is by looking at the date and dealing with
> the DST conversion depending on whether it's summer or winter.  That, of
> course, would be wildly inconsistent depending on where in the world you
> are.

Right. Couldn't agree more :-)

>>Sorry, I still don't understand. For calculating the UTC from a 
>>timestamp in a server response, how is the *client's* timezone and DST 
>>setting relevant?
> 
> 
> The client's DST setting is relevant *if* the server sends raw wallclock 
> timestamps with no DST adjustments.  In that case, the client can only 
> guess at the server's DST settings.  Is DST used?  If so, during which 
> part of the year?  The client can't know that information, so it uses its 
> own local information.
> 
> The client timezone is probably not used when converting the file 
> timestamps to UTC.

Yes, it is. That's what the source I'm complaining (ahem) about does.

>>Basically this means that the DST setting of the *client* machine on 
>>which JCifs is running is causing a 1-hour-shift for the *UTC* dates 
>>reported by SmbFile.
> 
> 
> That's possible (I think).
> 
> 
>>Is this really really intended?
> 
> 
> Again, it has to do with fundamental differences in the handling of time 
> between Windows and Unix.  Java time handling is based on Unix time 
> handling.

Yes, and this is good ;-) The question remains:

a) does the client need to do DST fixup?

b) if so, with which servers? my tests indicate that they shouldn't be 
done if the server is Windows 2K/2003?

c) if the client indeed needs to do DST fixup, how would using the 
*client* timezone & DST settings help here?

>>Well, we all agree that the system's behaviour is wrong, and we all can 
>>reproduce it. So it should be possible to identify thex exact component, 
>>right?
>>
>>Best regards and thanks for the feedback,
> 
> 
> I hope my ravings are of some use.  Urg.  This is very confusing.

I'm sure in the end we'll figure out.

Julian

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


More information about the jcifs mailing list