[jcifs] timezone problems

[Christopher R. Hertel]

On Tue, Mar 09, 2004 at 07:54:09PM +0100, Julian Reschke wrote:
:
> >If the [file] time[stamp] being reported via SMB is based on the 
> >*server's* local time [that is, if the SMB message contains the SMB_TIME 
> >and SMB_DATE as listed in FAT], then the client must convert the time [for 
> >display purposes] to the *client's* local time.
> 
> No, it doesn't have to.

Well, okay, I'm not being clear here.  I'm just trying to paint a picture 
of the situation that would show this.

> The SMB library itself is first of all required 
> to report the correct UTC-based timestamp (this is what the Java API is 
> about).

To be comaptible with java.io.File we have to convert the SMB_TIME and 
SMB_DATE values to Java UTC.

> Of course a client running on top of that can use the client's local 
> timezone settings to display the normalized UTC timestamp, but this is a 
> transformation that should occur *on top* of SmbFile.getLastModified().

Right, but that's the model I was working with.  :)

> >Since the file timestamps are stored in server local time (in FAT) I
> >assume that they are also reported that way via SMB.  To convert those
> >into UTC you also need to know the difference between server time and UTC.
> 
> I'm no SMB expert, and I have trouble following this description. If the 
> SMB protocol provides an UTC-based timestamp, and JCifs is supposed to 
> return UTC-based timestamps, why do we need a translation at this level?

At session startup the server returns a timestamp in bozoseconds
(10^-7) since Jan. 1 1601.  The client uses this to figure out the offset 
between the server's time and its own time.

The problem is that the FAT filesystem stores timestamps in local time, 
and SMB reports those times when reporting file timestamps.  The file 
timestamps do not contain Daylight Savings information, just the raw local 
time.  That's a royal pain, since the client has to figure out the 
Daylight Savings information of the server in order to convert the file 
timestamp information to UTC.

The same packet that returns the initial timestamp also returns a timezone 
offset.  That offset is the *current* offset from UTC.

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.

Anyway, as you can see this is complex.  It shouldn't be, but DOS, FAT, 
and SMB all have long and convoluted histories.  My guess is that 
upgrading to Samba 2.2.8a will fix this.  If not, then I'll run your code 
and do some captures to see what's different.

Thanks!

Chris -)-----

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