Subject: Re: [boost] Cross-platform date/time problems
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2009-11-03 02:43:53
Zachary Turner wrote:
> 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 on
>>>> 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
>>>> 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
>>>> 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
>>> 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
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk