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

Subject: Re: [boost] Cross-platform date/time problems
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-11-01 04:42:22

Zachary Turner wrote:
> Hello list,
> 
> Apologies for the cross-posting, this originally went to the boost-users
> list but it got no responses, and then I also realized it was actually more
> appropriate here.
> 
> Suppose I have a cross-platform agent that communicates with a server.
> Agent from platform X sends a message to the server which contains a
> date/time.  Server sends a message to another agent running platform Y with
> the same date/time.  In practice X/Y are always either windows/linux or
> linux/windows.  The server always tells the agent which platform's native
> format the time is represented in, so there should be no problem.  Ideally
> I'd like to write the following code:
> 
>     ptime time;
>     if (msg.is_from_windows())
>     {
>         time = from_ftime<ptime>(msg.time());
>     }
>     else
>     {
>         time = from_time_t(msg.time());
>     }
> 
> But this doesn't work because from_ftime<> is not defined on linux.  If
> from_ftime<> is already templated on the FILETIME type, is there any reason
> it needs to be #ifdef'd out on non-windows platforms?    I mean, a FILETIME
> is really just a uint64, can't the templated function also just operate on a
> boost::uint64_t?

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.

FWIW, it looks strange to me that you use the same field in the protocol 
to pass times in different formats depending on the OS. IMHO, the best 
way to go is to make the protocol OS-independent.