Re: Strategies for time offsets
- From: Stephen Hoffman <Hoff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 20 Nov 2006 13:24:56 -0500
JF Mezei wrote:
In VMS time, the sign of the time quadword indicates whether this is a delta time (-) or an absolute time (+). Right ?
The stored quadword value is a negative value for a positive offset. There isn't a mechanism for a negative delta time within the quadword storage, though applications are certainly free to stuff a sign bit somewhere (else).
The OpenVMS quadword time format is not something I would tend to implement in new code (particularly for storage), unless the code needs to maintain it for compatibility, or the format was part of formatting or other such operation. The (opaque) UTC format is often a better choice here, particularly when dealing with the storage of time values.
The OpenVMS quadword time format and the delta time scheme was certainly a good idea way back in 1976-1978, but there are better (or different) ways to do this sort of thing now. If the quadword wasn't so embedded in OpenVMS and within static storage and file structures and...
Is there some technique that would allow me to do something like this:
$descriptor(sydney_GMT_offset,"+0 11:00:00");
$descriptor(montreal_GMT_offset,"-0 05:00:00");
$DESCRIPTOR would help with the C macro I expect you're aiming for here, but I'd tend to use the DECdts (directly or indirectly) or other mechanism to maintain a UTC value and timezones as offsets. I'll leave somebody else to mention that UTC and GMT aren't the same thing. Well, then again, technically, they are the same thing, give or take a second or so.
do the sys$bintim (or equivalent)
And then, in the core of the program, I would simply need to do a LIB$ADD_TIMES (or whatever) and not have to worry about whether the offset is negative or positive.
True. You would need to worry about whether or not the offset is correct, however. These offsets vary by time of year, these offsets vary by year going back in time, and vary by the whim of whatever entity has a perceived need to adjust the offsets going forward in time.
I've certainly used lib$sub_times and lib$add_times over the years. lib$addx and lib$subx also work (and these RTL calls have been around for comparative eons), but do look at the sign bits when you use these calls -- you might need to use lib$subx to add values, for instance. With OpenVMS Alpha and OpenVMS I64 systems and compilers, you can also use the compiler-integrated math operations; the built in quadword math.
I am thinking it might be easier to just convert everything to unix time in seconds, at which point I can play with the sign in the offset and not have to worry about whether I should add or subtract the offset from the time value to get the current time over there.
If given a choice and the opportunity, I'd tend to maintain and use UTC timekeeping. UTC-format text strings for external interchange, and the opaque value for internal storage.
FWIW, the Unix epoch is 1-Jan-1970 to 19-Jan-2038, or through 2106 for unsigned values and operations.
NTP itself has a transition slightly ahead of that date; in 2036, as the next NTP era arrives during 8-Feb-2036.
The disadvantage of going to the Unix time is all the added overhead of converting it back to traditional VMS time/date display format.
I'd suggest optimizing these sorts of coding cases later. If you need to. It is very likely that the overhead of a few math operations will be entirely lost in the noise. It is also likely that getting the translation right and (better) foisting the effort off onto the system libraries is preferable to the effort of getting this translation right in your own code, and then maintaining the timezones. Barring cases where this timezone stuff is the bulk of the operation and there's nothing else around consuming more cycles or wallclock time -- I/O tends to be my go-to example here for massive overhead -- I'd tend to look to optimize this math stuff and any associated system call overhead later.
The other thing I just thought of is to check the first byte of the string for + or -, then pass only the remainder to SYS$BINTIM. I would then set the lowest order bit of the quadword to 1 of it is positive or 0 of negative. The routine that calculates the time would then check the low order bit to decide if one should add or subtract. I assume that the lowest order bit is inconsequantial for any time value whose resolution is within seconds ? This would really be a hack.
Any other suggestions ?
Specific calls of interest are the C timezone calls, UTC system service calls in OpenVMS, and my favorite hidden gem, the DECdts timezone libraries. These timezone libraries are present on any system with DECnet-Plus installed, and on all OpenVMS Alpha systems V7.3 and later, and on all OpenVMS VAX systems. See the V8.2 and later OpenVMS Utility Routines Manual for details on the UTC-related calls.
With time values in UTC, apply or set the timezone, and use the returned value as the offset, and then get the time into whatever format you need. (As I mentioned earlier, the UTC binary values are opaque, but they also tend to have all the ancillary details that avoid time-related maintenance and conversion and display problems.
I fully expect a few folks will discover embedded time and timezone errors in their local application code next year, when the US enjoys its first nationwide timezone-level changes in the professional lifetimes of many of the programmers. IIRC, the last changes in this area occurred in the 1970s and 1980s -- except for a few changes at the local level, the timezones and the daylight saving time (DST) settings haven't changed in roughly a quarter-century. These folks coded in the same basic approach you're looking to code here. The Australians -- my other go-to example for frequent timezone changes -- have changed the DST switch-overs twice in recent years, once for the Olympics and once for the Commonwealth Games. Maybe more?
If you're in UTC, get the offset from it for the target timezones, and convert from UTC to that localized value. You can run your math on UTC (either directly, or using the DECdts or OpenVMS UTC system service calls), and save the timezone-adjusted values for display to humans. It's a whole lot easier to maintain (internally) UTC values, too, as it saves needing to know the when and where to get the value of when, before you can use the when to get the local when. :-)
Some URLs:
http://h71000.www7.hp.com/doc/83final/4493/4493pro_contents_001.html#toc_chapter_9
http://en.wikipedia.org/wiki/Unix_time
http://en.wikipedia.org/wiki/Year_2038_problem
http://www.hoffmanlabs.com/vmsfaq/vmsfaq_004.html#faq_time
I'll leave you to decide if you want to deal with Unununium-format Time.
It's time (pun intended) to add a discussion of another set of TZ ECO kits (and the TZ ECO kits in general) into the discussion of the US Uniform Time Act of 1966 (15 U.S.C 260a(a)), as amended by the Energy Policy Act of 2005 present in the OpenVMS FAQ, but that's fodder for another thread and another discussion.
.
- Follow-Ups:
- Re: Strategies for time offsets
- From: JF Mezei
- Re: Strategies for time offsets
- References:
- Strategies for time offsets
- From: JF Mezei
- Strategies for time offsets
- Prev by Date: Re: Question: Can anyone write device drivers/
- Next by Date: Re: volume shadowing over LAVC ?
- Previous by thread: Re: Strategies for time offsets
- Next by thread: Re: Strategies for time offsets
- Index(es):
Relevant Pages
|
