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