[jcifs] timezone problems

[Julian Reschke]

Christopher R. Hertel wrote:

>>>If the time being reported via SMB is based on the *server's* local time, 
>>>then the client must convert the time to the *client's* local time.  To do 
>>>this, it uses the server time reported in the SMB Negotiate Protocol 
>>>Response.  That's that weird bozosecond timestamp.  The client must 
>>>compare the server's time against its own local time to calculate the 
>>>difference.
>>
>>Well, no. First of all, whatever the format on the wire is, JCifs needs 
>>to convert it to *UTC* (that is GMT w/o DST) first, because this is the 
>>format used by Java for timestamps (at least as java.io.File and SmbFile 
>>are concerned):
> 
> 
> That's what I was saying.
> 
> 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. The SMB library itself is first of all required 
to report the correct UTC-based timestamp (this is what the Java API is 
about).

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

> To do this [that is, provide the correct local time for display], it uses 
> the server time reported in the SMB Negotiate Protocol Response [which is 
> given as UTC based on Jan. 1 1601].
>
> That whole thing was about how the client would give the correct local 
> time from the client's perspective.

> 
>>Conversion to local timezones and DST considerations need to be done in 
>>the code *on top of* JCifs (for instance, by construcing Java Date 
>>objects and by formatting them using Java's locale support).
> 
> 
> Yes, but you can't do that unless you know the offset to the server's 
> time.  That's where the NegProt timestamp comes in.
> 
> 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?

>>>Note that calculating the time for display on the client does involve Java 
>>>doing a lot of time manipulations locally.  There's lots of opportunities 
>>>for subtle bugs at all levels.
>>
>>Yes. But this shouldn't occur at that level. SmbFile is a filie I/O API, 
>>not a user interface, and it's supposed to use UTC, not local time (at 
>>least I would assume so because this is was java.io.File does).
> 
> 
> So at which point do you apply the DST conversion in your code?
> Just curious...

I don't at all. I'm just trying to use SmbFile with the same semantics 
as java.io.File. For instance, on top of my code there's a CMS system 
running with WebDAV interfaces. These interfaces are only interested in 
UTC based timestamps, mapping that to some suited for a particular TZ is 
a user interface issue (for instace, done by the Microsoft Webfolder 
client).

>>>Does jCIFS return differnt values when running on, say, Linux vs. W2K and 
>>>accessing the same file?
>>
>>I'll try tomorrow.
> 
> 
> Looking forward to the results.

See separate mail...

Julian

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