Zachary Turner wrote:
On Sun, Nov 1, 2009 at 12:58 PM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
Zachary Turner wrote:
On Sun, Nov 1, 2009 at 3:42 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
Actually, FILETIME is a structure, the function just optimises its
operation by converting it to uint64_t internally, which may not be valid on Linux. Obviously, this structure is not available on Linux, so there's no way you can acquire it from OS.
for Windows platform and operate on FILETIME, not on some opaque uint64_t. FILETIME has additional value semantics, such as the base date and resolution. These semantics are not described for Linux.
I agree, but the point is that semantically a FILETIME is defined as "an opaque structure representing the number of 100-nanosecond intervals since January 1, 1601". Integer types are perfectly capable of representing exactly the same semantic definition, so why not? I don't think it even requires any code changes except to remove a single #ifdef in the date_time
The from_ftime function (and all other facilities it uses) are targeted header files.
It does. At least byte order issues should be taken into account.
Anyway, I don't think that bringing Windows-specific code to other platforms is a good idea. If you want cross-platform code, use cross-platform types, such as time_t, ptime or local_time.
That's just it, I'm trying to use ptime. A conversion has to exist somewhere, why shouldn't it exist in boost rather than me duplicating code for no particular benefit? If I decide that a unix epoch based time is going to be my "cross-platform network format" when I serialize / deserialize then I lose precision on Windows.
IUC you won't lose _precision_. The resolution of the timestamp might be in the order of 100s of nanoseconds, but the precision is somewhere in the order of tens of milliseconds under WinNT+.
If I decide that a windows epoch based time is going to be my cross platform network format, then I have to make an almost exact duplicate of the from_ftime function.
As Andrey suggested; if you're developing a cross-platform protocol, don't tie it to one of the platform's native format. Use a platform-neutral format. Why not just serialize the date/time as a sequence of integers (year,month,day,hour,min,sec,nanosecs) with a defined byte order, that represents the time (as GMT/UTC)?
Besides, my application does raw parsing of an NTFS filesystem. You can have NTFS filesystems on Linux. Usually the APIs abstract the fact that times are stored internally in the filesystem in FILETIME format, but that's no longer the case when you have raw access to the file systme.
Depending on how you actually use these timestamps, there could be a valid reason for using FILETIME as the wire format. Best regards, Johan Nilsson