Re: [boost] Cross-platform date/time problems

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
> <andrey.semashev_at_[hidden]>wrote:
>
>> Zachary Turner wrote:
>>
>>> On Sun, Nov 1, 2009 at 3:42 AM, Andrey Semashev
>>> <andrey.semashev_at_[hidden]>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.
>>>>
>>>>
>>>  The from_ftime function (and all other facilities it uses) are
>>> targeted
>>>> 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
>>> 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