[ace-users] ACE_OS::gettimeofday() - UTC or local ?

[Heiner Wolf]

Hi,

ACE version 5.4.1:

Is ACE_OS::gettimeofday() supposed to return the UTC time or the local
time?

On Win32 (XP Prof) using ::GetSystemTimeAsFileTime() it returns UTC
On Linux (Suse 9.1) ::gettimeofday() returns the local time

I noticed the difference, because I compile my app on both plattforms.

Can someone explain what this code snippet from "ace/OS_NS_sys_time.inl"
means:

# if defined (ACE_HAS_TIMEZONE_GETTIMEOFDAY) || \
(defined (ACE_HAS_SVR4_GETTIMEOFDAY) && !defined (m88k) && !defined
(SCO))
ACE_OSCALL (::gettimeofday (&tv, 0), int, -1, result);
# elif defined (VXWORKS) || defined (CHORUS) || defined (ACE_PSOS)
//...shortened
# else
ACE_OSCALL (::gettimeofday (&tv), int, -1, result);
# endif /* ACE_HAS_SVR4_GETTIMEOFDAY */

In other words:
if ACE_HAS_TIMEZONE_GETTIMEOFDAY then
::gettimeofday (&tv, 0)
else
::gettimeofday (&tv, 0)

Where is the difference? Supposed ACE_OS::gettimeofday() returns UTC,
shouldn't it convert from localtime to UTC, if HAS_TIMEZONE_GETTIMEOFDAY
?

hw
--
Dr. Klaus H. Wolf
bluehands GmbH & Co.mmunication KG
http://www.bluehands.de/people/hw
+49 (0721) 16108 75
--
Jabber enabled Virtual Presence on the Web: http://www.lluna.de/
Open Source Future History: http://www.galactic-developments.com/

[David Hawkins]

>
> ACE version 5.4.1:
>
> Is ACE_OS::gettimeofday() supposed to return the UTC time or the local
> time?
>
> On Win32 (XP Prof) using ::GetSystemTimeAsFileTime() it returns UTC
> On Linux (Suse 9.1) ::gettimeofday() returns the local time

I get UTC from Linux and ACE_OS::gettimeofday()
(using ACE ver 5.3b comes with the APG book).

The definition of gettimeofday is 'time since the UTC epoch'.
So the fact that you are getting local time is likely due to
a time configuration issue. I think the BIOS time can either
represent UTC or local. Look at the hwclock man page ... it
might have it in there.

What happens if you rdate or ntpdate to an NTP server?
Or simply

/usr/sbin/ntpq -p

if you are running NTP. If not set it up and sync to an
NTP server. That might help eliminate one possible issue.

Dave Hawkins
Caltech.

[Heiner Wolf]

Hi,

I checked "date" and "date -u":
video2# date
Sat Feb 12 18:49:06 CET 2005
video2# date -u
Sat Feb 12 17:49:23 UTC 2005
They are correct. I am UTC+1

But hwclock tells a different story:
video2# hwclock --localtime
Sat 12 Feb 2005 05:48:45 PM CET -0.630120 seconds
video2# hwclock --utc
Sat 12 Feb 2005 06:48:50 PM CET -0.443075 seconds
It says I am UTC-1 and UTC itself is shifted by 1 hour. I have to puzzle
that out.

A mystery remains. In the ACE lib there are lots of lines like:
ACE_Time_Value current_time = ACE_OS::gettimeofday();
I dont see any other initialising of ACE_Time_Value variables. I wonder
if it is relly meant to be UTC. Even in log lines would appear UTC, but
they don't. And this snippet from ace/OS_NS_sys_time.inl is still not
clear to me:

if ACE_HAS_TIMEZONE_GETTIMEOFDAY then
::gettimeofday (&tv, 0)
else
::gettimeofday (&tv, 0)

What is ACE_HAS_TIMEZONE_GETTIMEOFDAY about anyhow?

[Douglas C. Schmidt]

Hi Heiner,

>> ACE version 5.4.1:
>>
>> Is ACE_OS::gettimeofday() supposed to return the UTC time or the local
>> time?

It returns whatever the underlying OS is configured to return, i.e.,
if the underlying OS returns UTC then ACE_OS::gettimeofday() will do
the same.

>> On Win32 (XP Prof) using ::GetSystemTimeAsFileTime() it returns UTC
>> On Linux (Suse 9.1) ::gettimeofday() returns the local time
>>

>> I noticed the difference, because I compile my app on both plattforms.
>>
>> Can someone explain what this code snippet from "ace/OS_NS_sys_time.inl"
>> means:
>>
>> # if defined (ACE_HAS_TIMEZONE_GETTIMEOFDAY) || \
>> (defined (ACE_HAS_SVR4_GETTIMEOFDAY) && !defined (m88k) && !defined
>> (SCO))
>> ACE_OSCALL (::gettimeofday (&tv, 0), int, -1, result);
>> # elif defined (VXWORKS) || defined (CHORUS) || defined (ACE_PSOS)
>> //...shortened
>> # else
>> ACE_OSCALL (::gettimeofday (&tv), int, -1, result);
>> # endif /* ACE_HAS_SVR4_GETTIMEOFDAY */
>>
>> In other words:

>> if ACE_HAS_TIMEZONE_GETTIMEOFDAY then
>> ::gettimeofday (&tv, 0)
>> else
>> ::gettimeofday (&tv, 0)

I think you've copied the code incorrectly. Here's what it actually is:

if ACE_HAS_TIMEZONE_GETTIMEOFDAY then
::gettimeofday (&tv, 0)
else

::gettimeofday (&tv)

i.e., in the former case the OS supports an extra parameter for
::gettimeofday() that's the timezone, whereas in the latter it
doesn't.

Take care,

Doug

--
Dr. Douglas C. Schmidt, Professor TEL: (615) 343-8197
Electrical Engineering and Computer Science FAX: (615) 343-7440
Vanderbilt University WEB: www.cs.wustl.edu/~schmidt/
Nashville, TN 37203 NET: d.sc...@vanderbilt.edu

[Heiner Wolf]

Hi

>>> Is ACE_OS::gettimeofday() supposed to return the UTC time or the x

>>> local time?
>
>It returns whatever the underlying OS is configured to return, i.e.,
>if the underlying OS returns UTC then ACE_OS::gettimeofday() will do
>the same.

I need advice. What is the recommended way to initialize ACE_Time_Value
to the current local date/time. I have a date and time as strings. I
convet this to an ACE_Time_Value. Then I compare this with the current
local time. So, I do:

ACE_Time_Value current_time = ACE_OS::gettimeofday();

Is this correct or is there a better way to ENSURE that I get a local
time, like maybe ACE_OS::getlocaltime() or the like.

>I think you've copied the code incorrectly.

You are right. Now I understand what the ACE_HAS_TIMEZONE_GETTIMEOFDAY
thing is.

[Thomas Lockhart]

>>>>Is ACE_OS::gettimeofday() supposed to return the UTC time or the x
>>>>local time?
>>It returns whatever the underlying OS is configured to return, i.e.,
>>if the underlying OS returns UTC then ACE_OS::gettimeofday() will do
>>the same.

To be more specific, the underlying OS implementation of gettimeofday()
always respects system timezone settings, including process-specific
settings of the TZ environment variable. So one should probably consider
this as returning "local time".

> I need advice. What is the recommended way to initialize ACE_Time_Value
> to the current local date/time.

You must have or provide some trustworthy way of specifying the local
time zone offsets and conventions. Unfortunately if you can't trust your
local machine to be set to the correct time zone, you must specify that
at the application level by setting TZ before the application starts or
from within the application. afaik that is also true if you want UTC to
sub-second precision.

fwiw I did most of the date/time handling for PostgreSQL. Time zones
suck, but can provide many hours of coding pleasure ;)

- Tom

--
Thomas Lockhart
Supervisor, Realtime Software Group
Interferometry and Large Optical Systems
Caltech/JPL