Subject: Re: [boost] Cross-platform date/time problems
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-11-02 12:12:38
On Sun, Nov 1, 2009 at 12:58 PM, Andrey Semashev
> Zachary Turner wrote:
>> On Sun, Nov 1, 2009 at 3:42 AM, Andrey Semashev
>> Actually, FILETIME is a structure, the function just optimises its
>>> operation by converting it to uint64_t internally, which may not be valid
>>> Linux. Obviously, this structure is not available on Linux, so there's no
>>> way you can acquire it from OS.
>> The from_ftime function (and all other facilities it uses) are targeted
>>> 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
>> 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. 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.
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.