[jcifs] timezone problems
Michael B Allen
mba2000 at ioplex.com
Wed Mar 10 03:50:24 GMT 2004
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.
Basically your program creates a java.io.File with a time of Jun 21 8PM
but if you look at this timestamp in Windows Explorer it reads 7PM. That
in itself is suspect. If I run the program on Linux with Samba 2.2.8a it
works and all the timestamps match up. At one point you suggested there's
a bug in Samba that's cancelling out a bug in jCIFS but if you 'stat' the
files in Linux the times are still right. So the only deviant is
java.io.File on Windows.
>> To be comaptible with java.io.File we have to convert the SMB_TIME and
>> SMB_DATE values to Java UTC.
> Great, it's good we have agreement here :-)
I don't see where UTC comes in. I'm in NYC which is -5 so that alone
doesn't account for a descrepency of 1 hour.
>> Anyway, I don't know the "normal" way of handling these file timestamps.
>> I have not tested this part of the protocol (recently), but assume that
>> all clients simply adjust the SMB_TIME and SMB_DATE by using the
>> ServerTimeZone info provided in the NegProt at the start of the session.
> But what's happening in the code above is that the *client's* timezone
> and DST settings are used for the adjustment. How is this supposed to be
> correct, unless both server and client happen to be in the same timezone?
It's been a long while since I worked through this stuff and I never rule
out the possabilty for a bug when working with CIFS but if you look at 3.7
in the "CIFS Technical Reference" it claims timestamps are UTC but then
explains that they "include an additional correction factor" of *the
daylight savings in effect at the time the file was created/modified*
minus the current daylight savings.
So if the client is given the server time and timestamps emitted are
relative to that you need to correct the "correction factor" by adjusting
for DST and the difference between the server's TZ (provided in the
negprot response) and your own (the clients) TZ.
It's crazy enough that the calculation we're using could be wrong but
currently I don't see a problem.
More information about the jcifs