[jcifs] timezone problems

Julian Reschke julian.reschke at gmx.de
Tue Mar 9 19:47:59 GMT 2004

Christopher R. Hertel wrote:

> 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 
> 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 :-)

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

OK, so that's clarified now. It's not the model that applies to the Java 
UTC long timestamps used by SmbFile.

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

That doesn't seem to be consistent with the code I'm looking at...:

     static long readTime( byte[] src, int srcIndex ) {
         int low = readInt4( src, srcIndex );
         int hi = readInt4( src, srcIndex + 4 );
         long t = ((long)hi << 32 ) | ( (long)low & 0xFFFFFFFFL );
         t = ( t / 10000L - MILLISECONDS_BETWEEN_1970_AND_1601 );

         synchronized( TZ ) {
             if( TZ.inDaylightTime( new Date() )) {
                 // in DST
                 if( TZ.inDaylightTime( new Date( t ))) {
                     // t also in DST so no correction
                     return t;
                 // t not in DST so add 1 hour
                 return t + 3600000;
             } else {
                 // not in DST
                 if( TZ.inDaylightTime( new Date( t ))) {
                     // t is in DST so subtract 1 hour
                     return t - 3600000;
                 // t isn't in DST either
                 return t;

This certainly looks like code that unpacks a 64-bit timestamp, not a 
FAT timestamp....

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

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?

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

The issue was triggered by JCifs' behaviour against a Windows2000 server 
(same for Windows 2003). I only tested Samba because you asked me to do 
so. As a matter of fact this was a good thing to do, because it shows 
that at least *that* Samba version behaves differently than W2K.


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

More information about the jcifs mailing list