[jcifs] timezone problems
julian.reschke at gmx.de
Tue Mar 9 18:54:09 GMT 2004
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
>>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
> 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
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
>>>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...
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
More information about the jcifs