views:

1307

answers:

3

I discovered a strange result in Boost C++ date time library. There is inconsistency between microsec_clock and second_clock, and I don't understand why is that. I am using Windows XP 32-bits

My snip of code:

using namespace boost::posix_time;
...
ptime now = second_clock::universal_time();
std::cout << "Current Time is: "<< to_iso_extended_string(now)<< std::endl;
ptime now_2 = microsec_clock::universal_time();
std::cout << "Current Time is: "<< to_iso_extended_string(now_2)<< std::endl;
...

The print-out I expected are current time without miliseconds and with milliseonds. However, what I have in my pc is:

2009-10-14T16:07:38  
1970-06-24T20:36:09.375890

I don't understand why there is a weired date (year 1970???) in my microsec_clock time. Related documentation for Boost: link to boost date time

Newbie in Boost, any suggestion will help.

Lily

A: 

The 1970 date most likely comes from the way unix time is represented, as seconds from January 1 1970. I would guess that maybe it is somehow getting the system uptime in milliseconds and interpreting it as seconds since 1/1/1970. An uptime of a little over 4 hours would come up with this date.

Dolphin
A: 

Unlike second_clock, the microsec_clock::universal_time documentation mentions: Returns the UTC time based on computer settings.
You should check your hardware clock settings (or where-ever microsec gets its values from).

edit:
If its not related to your computers settings it would have to be an misbehaviour in boost, which i highly doubt.

Georg Fritzsche
Very good point, and I also found this: Get the UTC time using a sub second resolution clock. On Unix systems this is implemented using GetTimeOfDay. On most Win32 platforms it is implemented using ftime. Win32 systems often do not achieve microsecond resolution via this API. If higher resolution is critical to your application test your platform to see the achieved resolution.===>I am using Win32 system, so maybe there is no such resolution at all in my pc. That might be the reason. However, the print-out did give me a date, then where do those numbers come from?...
Lily
Implementation-wise it generates a time_type from the current date and ftime() in create_time() if i see that right.
Georg Fritzsche
And if ftime() doesn't support sub second resolution i'd expect to lose the high resolution and a fallback to the next-best resolution.
Georg Fritzsche
https://svn.boost.org/trac/boost/ticket/2809 Misbehavior in Boost may be more likely than you think.
ephemient
Ok, but in general less likely then user mistakes or invalid settings. This seems to be limited to MingW - for me it works fine on WinXP/VC8/boost 1.38.
Georg Fritzsche
+2  A: 
ephemient
I am using Win32 system, Windows XP SP2 32 bits to be exact.
Lily
I am using 1.39 already with Eclipse 3.4.1 and MingW 3.4. Also, I am having the warning: Description Resource Path Location TypeC:/boost/boost_1_39/boost/date_time/filetime_functions.hpp left shift count >= width of type CommercialDetection line 101 C/C++ Problem as well
Lily
Hmm, I thought this fix was in 1.39 but I can double-check.
ephemient