[jcifs] timezone problems

Christopher R. Hertel crh at ubiqx.mn.org
Wed Mar 10 22:15:47 GMT 2004

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.


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.

> >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.
> Yes, it says that (but it doesn't say that in the earlier draft).

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

> Anyway. If there is a DST adjustment in the servers response, how does 
> checking the *client's* timezone setting is supposed to help computing 
> the UTC???

If the client gets the wallclock time from the server (my theory) then the
client must make two adjustments to translate that to a UTC timestamp.  
First, it adjusts the file timestamp based on the ServerTimeZone returned
in the NegProt Reponse.  Then it must apply DST based *on file timestamp

That all assumes that we're getting the raw wallclock time over the wire 
in the SMB_DATE and SMB_TIME fields.  It would make more sense if the 
server were to make the DST adjustment since the server knows how it's 
configured with respect to timezones and DST.  I doubt that happens, 

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

> 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 

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

Chirdz -)-----

"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org

More information about the jcifs mailing list