Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at