At 06:14 PM 12/16/00 -0800, Guy Harris wrote:
>> OK, it seems to me that NT uses a different date/time format,
>
>To quote one of the CIFS drafts:
>
> 3.5 Time And Date Encoding
>
> When SMB requests or responses encode time values, the following
> describes the various encodings used.
>
> struct {
> USHORT Day : 5;
> USHORT Month : 4;
> USHORT Year : 7;
> } SMB_DATE;
>
> The Year field has a range of 0-119, which represents years 1980
> - 2099. The Month is encoded as 1-12, and the day ranges from
> 1-31
>
> struct {
> USHORT TwoSeconds : 5;
> USHORT Minutes : 6;
> USHORT Hours : 5;
> } SMB_TIME;
>
> Hours ranges from 0-23, Minutes range from 0-59, and TwoSeconds
> ranges from 0-29 representing two second increments within the
> minute.
>
> typedef struct {
> ULONG LowTime;
> LONG HighTime;
> } TIME;
>
> TIME indicates a signed 64-bit integer representing either an
> absolute time or a time interval. Times are specified in units
> of 100ns. A positive value expresses an absolute time, where
> the base time (the 64- bit integer with value 0) is the
> beginning of the year 1601 AD in the Gregorian calendar. A
> negative value expresses a time interval relative to some base
> time, usually the current time.
>
> typedef unsigned long UTIME;
>
> UTIME is the number of seconds since Jan 1, 1970, 00:00:00.0.
>
>SMB_DATE and SMB_TIME are DOS-style dates and times; UTIME is a
>UNIX-style time (although I think it's seconds since Jan 1, 1970,
>00:00:00.0 *local* time, not Jan 1, 1970, 00:00:00.0 GMT), and TIME is
>what, in Win32, is called a "FILETIME".
>
>It's UNIX-like, in that it's time ticks since a fixed epoch, but the
>epoch is different, and, instead of being seconds, or seconds plus a
>microsecond offset as two numbers, or seconds plus a nanosecond offset
>as two numbers, it's tenths of microseconds as one number.
OK, I have seen that stuff as well. What I cannot understand yet is that
Windows 95 understands both the UTIME format returned by Samba, which is
definitely seconds since 1970 (in localtime), as well as what NT is returning.
So, there is some state info it is getting hold of.
Where did you get that info about number of 10ths of a second?
>(UTIME is what appears in the document "Microsoft Networks/OpenNET FILE
>SHARING PROTOCOL, INTEL Part Number 138446, Document Version 2.0", from
>November 7, 1988.
Hmmm, I seem to have misplaced my copies of this document :-(
>SMB_DATE and SMB_TIME appear in "Microsoft Networks SMB FILE SHARING
>PROTOCOL EXTENSIONS, SMB File Sharing Protocol Extensions Version 2.0,
>Document Version 3.3", also from November 7, 1988, which says it's for
>"Operating Systems richer in function than MS-DOS 3.x", and cites OS/2.
>
>I wonder whether UTIME was used when they thought Xenix was the server
>OS of choice, and SMB_DATE/SMB_TIME was used when they thought OS/2 was
>the server OS of choice, and, now that NT, even if NT 5.0 has been
>renamed "Windows 2000", is the server OS of choice, they use TIME.)
>
>It appears that NetApp's servers return UTIME in response to the core
>"get attributes" request, which agrees with the "Microsoft
>Networks/OpenNET FILE SHARING PROTOCOL" document, so I don't know what
>the deal is with that packet.
>
Regards
-------
Richard Sharpe, sharpe@xxxxxxxxxx
Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org)
Contributing author, SAMS Teach Yourself Samba in 24 Hours
Author, Special Edition, Using Samba