[jcifs] timezone problems
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
>>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.
> 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
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
> 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
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,
>>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.
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
More information about the jcifs