Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Possible time discrepancy?

 
SOLVED
Go to solution
David Heitmann
Occasional Contributor

Possible time discrepancy?

The time returned by the clock_gettime function does not seem to give the expected time when compared to the system time as returned by the sys$gettim function. Shouldn't the values differ by the time between 17-NOV-1858 and 1-JAN-1970? Not only do I not get the value I'd expect, but on an Itanium running V8.3-1H1 the delta is 7 hours while on an Alpha running E8.2 the delta is 5 hours. Am I missing something?
Here's a sample program to show what I mean:

#include
#include
#include
#include
#include
#include

#define TICKS_PER_SEC 10000000LL

static $DESCRIPTOR(dt, "1-JAN-1970 00:00:00.0");

int main()
{
__int64 epoch, tm, t;
struct timespec clk;

/*
* The epoch should be last 45 days of 1858 (from Nov 17)
* plus 365 days/year for 111 years (1859 through 1969)
* plus 27 days for leap years = 40587 days
* or 3506716800 seconds
* or a system time of 35067168000000000
*/
lib$convert_date_string(&dt, &epoch);
printf("lib$convert_date_string gives %lld as the epoch...", epoch);
if (epoch == 35067168000000000LL)
printf("correct\n\n");
else {
printf("wrong\n\n");
return EXIT_FAILURE;
}

/*
* The epoch should be the difference between these times.
*/
clock_gettime(CLOCK_REALTIME, &clk);
sys$gettim(&tm);

t = ((__int64) clk.tv_sec) * TICKS_PER_SEC
+ ((__int64) clk.tv_nsec) / 100;

printf("system time : %lld\n", tm);
printf("- clock_gettime : %lld\n", t);
printf("= difference : %lld\n", tm - t);
printf("- epoch : %lld\n", epoch);
printf("= off by : %lld\n", tm - t - epoch);

return EXIT_SUCCESS;
}
4 REPLIES 4
Hoff
Honored Contributor

Re: Possible time discrepancy?

Why are you even looking at an E8.2 box? That was an early field test of V8.2, and even V8.2 is a bad idea by now.

I suspect the difference here is due to the use of 17-NOV-1858 in localtime, and the use of 1-Jan-1970 in UTC, and the timezone settings.

I'm disinclined to debug this C code to prove this theory, given the use of E8.2 here, and given that tested and working and portable OpenVMS epoch time conversion code is available here:

http://labs.hoffmanlabs.com/node/735
David Heitmann
Occasional Contributor

Re: Possible time discrepancy?

The discrepancy does indeed match the timezone offset, but I don't see why that should be the case. My understanding is that time() and clock_gettime() return seconds since the epoch, and should not be affected by the time zone. Does that mean that the time zone has to be set to UTC to intermix those function calls with sys$gettim in the same application?
Hoff
Honored Contributor
Solution

Re: Possible time discrepancy?

If you'd like to see the same values, set your OpenVMS time to GMT/UTC. Problem solved.

OpenVMS uses its own 17-Nov-1858 epoch; the saved time is the number of centiseconds since that time, local. Local. Not GMT. Usually stored in a quadword.

Classic OpenVMS system services do not know about timezones and such. It's all local time, as far as the classic services are concerned.

OpenVMS uses local time as the time base. Not GMT/UTC. No DST.

Newer services can deal with TZs, but the older ones don't.

Unix and C uses its own 1-Jan-1970 epoch, and uses GMT/UTC as its base time.

Unix calls return either the epoch GMT/UTC or returns localtime, depending on the call.

The Unix C calls do the time-math to get from the OpenVMS native base time maintained by and within OpenVMS to GMT/UTC and then (if needed) along to localtime as required. (BTW: when this particular stuff isn't fully and correctly configured and current on its rules around daylight saving time (DST), you'll end up with the time off by an hour; time values reported by OpenVMS and Unix will be reported differently.)

Follow the timekeeping link around on the site I referenced. I've posted a whole lot on this topic over there.

http://labs.hoffmanlabs.com/taxonomy/term/57

pedant note 1: Yes, I'm aware that GMT and UTC are not the same.
pedant note 2: Yes, I'm aware that there can be optimizations made in the C time calculations.
David Heitmann
Occasional Contributor

Re: Possible time discrepancy?

Though I don't particularly like the idea of having to set the time zone to UTC, I do understand the issue now. Thank you for your help.