[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::decc

Title:DECC
Notice:General DEC C discussions
Moderator:TLE::D_SMITHNTE
Created:Fri Nov 13 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2212
Total number of notes:11045

2170.0. "localtime and tdf value?" by CSC32::J_HENSON (Don't get even, get ahead!) Tue Apr 29 1997 13:47

c++, openvms v7.1, alpha

A customer is reporting behavior with the localtime function that I
don't quite understand, so I'm posting this note in hopes that someone
can shed some light on what is going on.  Unfortunately, to test
this claim for myself requires that I find a system on which I
can change some of the time parameters, so I haven't been able to do it.

This customer is calling locatime and examining the results.  He
is NOT using the macros to force v4.0 or ovms v6.x behavior, so he
is using utc as his time standard.

The problem began when he noticed that the hour field (tm_hour) was
off by one from that shown by the dcl $show time command.  After
some further investigating, he realized that his system time differential
(TDF) was off, and used the utc$configure_tdf.com procedure to change it.  
The effect of this was that the hour field is now correct.  So far so
good.

However, his claim is that after changing the system tdf field as
described above, neither the tm_isdst nor tm_gmtoff field values returned
by localtime did changed.  Both the offest and dst values remained
the same after changing the system tdf.  His expectation was that a change
to the system tdf should be reflected in the tm_gmtoff value
returned by localtime, but that it isn't.

His concern of that is he doesn't know how to accurately interpret the 
results from localtime.  If he changes the system tdf value, he sees
the difference reflected in the tm_hour value, but nowhere else.  Is
this right?  Where should the tm_gmtoff value come from?

Thanks,

Jerry
T.RTitleUserPersonal
Name		DateLines
2170.1ensure "daylight" timezoneCUJO::SAMPSONTue Apr 29 1997 14:3723
    Jerry,
    
    	Here's an unofficial (and probably incomplete) answer.
    I went through this drill with a customer recently.  Their
    problem was that local time was set to the correct hour,
    but the timezone was configured as standard (PST), when it
    should currently be daylight (PDT).  This caused the returned
    values from both localtime() and gmtime() to be one hour ahead
    of what they should have been.  After using SYS$MANAGER:UTC*.COM
    and a big hammer (define/system/exec for the SYS$TIMEZONE* logicals),
    their systems are all on daylight time, and localtime() and gmtime()
    both return the expected values.  However, this condition is likely
    to hold only until the next reboot, or until local time reverts to
    standard.  The reason is that full timezone support, including the
    automatic daylight-standard transitions, requires a product like
    DTSS or NTP to be properly configured and running.  This particular
    customer is currently shying away from DECnet/OSI, and running
    DECnet Phase IV on all systems except one.  DTSS is now tightly
    integrated with DECnet/OSI, so they *must* run DECnet/OSI to run DTSS.
    
    	HTH,
    	Bob Sampson
2170.2more detailsCSC32::J_HENSONDon't get even, get ahead!Wed Apr 30 1997 11:3663
Thanks, Bob.  I still don't understand what's going on, though.  It's
hard for me to determine if localtime is producing correct results    
or not.

So, I have done the following.  See the next reply for a sethost.log
file of what I have summarized below.

This was done on an openvms alpha system running openvms v7.0 and
dec c v5.5-003.  The source for the program I am running is
included in the next reply, but basically it calls localtime and
displays various parts of the returned structure.

Here's a summarization of my results, plus some of my comments.

- log in and issue the $show time command.  Time is 7:41.

- run my getlt program.  It shows time to be 7:41, tm_hour = 7,
	tm_isdst = 1, tm_gmtoff = -21600 and tm_zone = MDT.  This
	looks good to me.

- execute sys$manager:utc$configure_tdf.com
  - show option shows tdf to be -6:00 (-21600) and local time 7:42
  - change tdf from -6:00 to -5:00 (-18000).
  - leave local time unchanged

- run getlt.  Results are: time is 7:43, tm_hour = 7, tm_isdst = 1,
		tm_gmtime=-21600 and tm_zone = MDT
  Note that even though I have changed the TDF using utc$configure_tdf.com,
		the tdf value returned in tm_gmtime is unchanged.

- execute uct$configure_tdf.com again.  This time,
  - show option shows tdf to be -5:00 (-18000) and local time to be
	7:43.
  - change tdf back to -6:00 and leave local time as.

- run getlt.  local time is 7:43, tm_hour = 7, isdst =1, gmtoff = -21600
	and tm_zone = MDT.  This is basically back to where we started.

- execute utc$configure_tdf.  This time,
  - show option shows tdf = -6:00 and time is 7:43
  - change tdf to -5:00 and local time to -1:00. 
  - the local time displayed by this procedure shows local time now
    to be 6:44.

- run getlt.  Time is now 5:44 , tm_hour = 5, tm_isdst = 1, tm_gmtoff = -21600
	and tm_zone = MDT
  Note that tm_gmtoff is still unchanged, but that the local time has
	changed by 2 hours.

- execute utc$configure_tdf to set tdf and localtime back to starting
	values.  Getlt reflect original value.  Log off.

So, my question is still where does localtime get the tm_gmtoff value?  It's
not getting it from changes made by utc$configure_tdf.  On the other hand,
changing the tdf using utc$configure_tdf does change the tm_hour value
returned by localtime, even though it's in conflict with the local system
time reflected by the utc$configure_tdf procedure.

Something doesn't seem right to me.  Shouldn't localtime be in agreement
with the localtime and tdf that is recognized by the utc$configure_tdf
procedure?

Jerry
2170.3sethost.log fileCSC32::J_HENSONDon't get even, get ahead!Wed Apr 30 1997 11:37311
 Welcome to OpenVMS Alpha (TM) Operating System, Version V7.0    

Username: J_HENSON
Password: 

                 Welcome to Node SUPAI Running OpenVMS Alpha

                              Internal Use Only

             ***  Unauthorized Access To This Node Prohibited ***

         +---------------------------------------------------------+
         |              For Help, contact Elin Vaeth               |
         |             592-4887, [email protected]               |
         +---------------------------------------------------------+
    Last interactive login on Wednesday, 30-APR-1997 07:19:34.25
    Last non-interactive login on Monday,  3-MAR-1997 15:14:30.50
SUPAI> set proc/priv=all
SUPAI> sho tim
  30-APR-1997 07:41:32
SUPAI> type getlt.c
#include <stdio.h>
#include <time.h>
main()
{
	time_t t;
	struct tm *local_time;
	t = time((time_t)0);
	local_time = localtime(&t);
	printf("The current time is: %s\n",asctime(local_time));
	printf("localtime returned the following \n");
	printf("tm_hour = %d\n",local_time->tm_hour);
	printf("tm_isdst = %d\n",local_time->tm_isdst);
	printf("tm_gmtoff = %d\n",local_time->tm_gmtoff);
	printf("tm_zone = %s\n",local_time->tm_zone);
}
SUPAI> cc getlt
SUPAI> link getlt
SUPAI> r getlt
The current time is: Wed Apr 30 07:41:57 1997

localtime returned the following 
tm_hour = 7
tm_isdst = 1
tm_gmtoff = -21600
tm_zone = MDT
SUPAI> @sys$manager:utc$configure_tdf


    Configuring the Time Differential Factor (TDF)

    Enter ? anytime for help

    [0]     Exit
    [1]     Set the Time Differential Factor
    [2]     Display the Time Differential Factor

Please pick an option number [2]: 2

    SYSTEM TIME DIFFERENTIAL FACTOR = -6:00  (-21600 seconds).
    LOCAL SYSTEM TIME               = 30-APR-1997 07:42:11.72.



    Configuring the Time Differential Factor (TDF)

    Enter ? anytime for help

    [0]     Exit
    [1]     Set the Time Differential Factor
    [2]     Display the Time Differential Factor

Please pick an option number [2]: 1


    The Time Differential Factor (TDF) is the difference between your
    system time and Coordinated Universal Time (UTC).  UTC is similar
    in most repects to Greenwich Mean Time (GMT).

    The TDF is expressed as hours and minutes, and should be entered
    in the hh:mm format.  TDFs for the Americas will be negative
    (-3:00, -4:00, etc.); TDFs for Europe, Africa, Asia and Australia
    will be positive (1:00, 2:00, etc.).


Enter the Time Differential Factor: -5:00

    If this is a seasonal time change, it may also be necessary to
    modify the system time.  Generally, seasonal time changes result
    in adding 1:00 hour, or adding -1:00 hour to the system time.

Do you wish to modify the local system time [N]: 

    NEW SYSTEM TIME DIFFERENTIAL FACTOR = -5:00.

Is this correct? [Y]: 

    SYSTEM TIME DIFFERENTIAL FACTOR = -5:00  (-18000 seconds).
    LOCAL SYSTEM TIME               = 30-APR-1997 07:42:33.91.

SUPAI> r getlt
The current time is: Wed Apr 30 06:42:38 1997

localtime returned the following 
tm_hour = 6
tm_isdst = 1
tm_gmtoff = -21600
tm_zone = MDT
SUPAI> @sys$manager:utc$configure_tdf


    Configuring the Time Differential Factor (TDF)

    Enter ? anytime for help

    [0]     Exit
    [1]     Set the Time Differential Factor
    [2]     Display the Time Differential Factor

Please pick an option number [2]: 2

    SYSTEM TIME DIFFERENTIAL FACTOR = -5:00  (-18000 seconds).
    LOCAL SYSTEM TIME               = 30-APR-1997 07:42:52.54.



    Configuring the Time Differential Factor (TDF)

    Enter ? anytime for help

    [0]     Exit
    [1]     Set the Time Differential Factor
    [2]     Display the Time Differential Factor

Please pick an option number [2]: 1


    The Time Differential Factor (TDF) is the difference between your
    system time and Coordinated Universal Time (UTC).  UTC is similar
    in most repects to Greenwich Mean Time (GMT).

    The TDF is expressed as hours and minutes, and should be entered
    in the hh:mm format.  TDFs for the Americas will be negative
    (-3:00, -4:00, etc.); TDFs for Europe, Africa, Asia and Australia
    will be positive (1:00, 2:00, etc.).


Enter the Time Differential Factor: -6:00

    If this is a seasonal time change, it may also be necessary to
    modify the system time.  Generally, seasonal time changes result
    in adding 1:00 hour, or adding -1:00 hour to the system time.

Do you wish to modify the local system time [N]: n

    NEW SYSTEM TIME DIFFERENTIAL FACTOR = -6:00.

Is this correct? [Y]: 

    SYSTEM TIME DIFFERENTIAL FACTOR = -6:00  (-21600 seconds).
    LOCAL SYSTEM TIME               = 30-APR-1997 07:43:13.78.

SUPAI> r getlt
The current time is: Wed Apr 30 07:43:18 1997

localtime returned the following 
tm_hour = 7
tm_isdst = 1
tm_gmtoff = -21600
tm_zone = MDT
SUPAI> @sys$manager:utc$configure_tdf


    Configuring the Time Differential Factor (TDF)

    Enter ? anytime for help

    [0]     Exit
    [1]     Set the Time Differential Factor
    [2]     Display the Time Differential Factor

Please pick an option number [2]: 2

    SYSTEM TIME DIFFERENTIAL FACTOR = -6:00  (-21600 seconds).
    LOCAL SYSTEM TIME               = 30-APR-1997 07:43:41.01.



    Configuring the Time Differential Factor (TDF)

    Enter ? anytime for help

    [0]     Exit
    [1]     Set the Time Differential Factor
    [2]     Display the Time Differential Factor

Please pick an option number [2]: 1


    The Time Differential Factor (TDF) is the difference between your
    system time and Coordinated Universal Time (UTC).  UTC is similar
    in most repects to Greenwich Mean Time (GMT).

    The TDF is expressed as hours and minutes, and should be entered
    in the hh:mm format.  TDFs for the Americas will be negative
    (-3:00, -4:00, etc.); TDFs for Europe, Africa, Asia and Australia
    will be positive (1:00, 2:00, etc.).


Enter the Time Differential Factor: -5:00

    If this is a seasonal time change, it may also be necessary to
    modify the system time.  Generally, seasonal time changes result
    in adding 1:00 hour, or adding -1:00 hour to the system time.

Do you wish to modify the local system time [N]: y

    Enter the time adjustment value you would like to add
    to the local time.  The value can be a positive or a
    negative (-hh:mm) value.

Enter the time adjustment value: -1:00

    NEW SYSTEM TIME DIFFERENTIAL FACTOR = -5:00.
    ADDING -1:00 TO THE LOCAL TIME.

Is this correct? [Y]: 

    SYSTEM TIME DIFFERENTIAL FACTOR = -5:00  (-18000 seconds).
    LOCAL SYSTEM TIME               = 30-APR-1997 06:44:02.04.

SUPAI> r getlt
The current time is: Wed Apr 30 05:44:04 1997

localtime returned the following 
tm_hour = 5
tm_isdst = 1
tm_gmtoff = -21600
tm_zone = MDT
SUPAI> @sys$manager:utc$configure_tdf


    Configuring the Time Differential Factor (TDF)

    Enter ? anytime for help

    [0]     Exit
    [1]     Set the Time Differential Factor
    [2]     Display the Time Differential Factor

Please pick an option number [2]: 2

    SYSTEM TIME DIFFERENTIAL FACTOR = -5:00  (-18000 seconds).
    LOCAL SYSTEM TIME               = 30-APR-1997 06:44:18.86.



    Configuring the Time Differential Factor (TDF)

    Enter ? anytime for help

    [0]     Exit
    [1]     Set the Time Differential Factor
    [2]     Display the Time Differential Factor

Please pick an option number [2]: 1


    The Time Differential Factor (TDF) is the difference between your
    system time and Coordinated Universal Time (UTC).  UTC is similar
    in most repects to Greenwich Mean Time (GMT).

    The TDF is expressed as hours and minutes, and should be entered
    in the hh:mm format.  TDFs for the Americas will be negative
    (-3:00, -4:00, etc.); TDFs for Europe, Africa, Asia and Australia
    will be positive (1:00, 2:00, etc.).


Enter the Time Differential Factor: -6:00

    If this is a seasonal time change, it may also be necessary to
    modify the system time.  Generally, seasonal time changes result
    in adding 1:00 hour, or adding -1:00 hour to the system time.

Do you wish to modify the local system time [N]: y

    Enter the time adjustment value you would like to add
    to the local time.  The value can be a positive or a
    negative (-hh:mm) value.

Enter the time adjustment value: 1:00

    NEW SYSTEM TIME DIFFERENTIAL FACTOR = -6:00.
    ADDING 1:00 TO THE LOCAL TIME.

Is this correct? [Y]: 

    SYSTEM TIME DIFFERENTIAL FACTOR = -6:00  (-21600 seconds).
    LOCAL SYSTEM TIME               = 30-APR-1997 07:44:35.29.

SUPAI> r getlt
The current time is: Wed Apr 30 07:44:41 1997

localtime returned the following 
tm_hour = 7
tm_isdst = 1
tm_gmtoff = -21600
tm_zone = MDT
SUPAI> lo
  J_HENSON     logged out at 30-APR-1997 07:44:44.09
2170.4with DECnet/OSI, NET$CONFIGURE should workCUJO::SAMPSONThu May 01 1997 01:2424
	Jerry,

	After you have correctly configured the TDF, try checking and
setting the SYS$TIMEZONE* logical names manually.  This is what I had
to do, when DECnet/OSI and DTSS were not available.  Alternatively,
if you do have DECnet/OSI (and integrated DTSS), execute the procedure
SYS$MANAGER:NET$CONFIGURE.COM, and follow the menu to configure the
DTSS TDF.  This should be menu item [5].  In either case, the logicals
should end up looking something like:

$ show logical/full sys$timezone*
...
  "SYS$TIMEZONE_DAYLIGHT_SAVING" [exec] = "1"
  "SYS$TIMEZONE_DIFFERENTIAL" [exec] = "-21600"
  "SYS$TIMEZONE_NAME" [exec] = "MDT"
  "SYS$TIMEZONE_RULE" [exec] = "MST7MDT6,M4.1.0/2,M10.5.0/2"
...

	Apparently these logicals are defined at DTSS startup time,
and only updated as necessary thereafter.  The UTC*.COM procedures
apparently update a data file, but do not update all of the logicals.

	HTH,
	Bob Sampson
2170.5every time a new TZ Rule is issued, I have to..COMEUP::SIMMONDSloose canonThu May 01 1997 02:253
    Re: .3,.4
    
    Yep, you have to delete the old SYS$TIMEZONE* logicals first..
2170.6How is it supposed to work?CSC32::J_HENSONDon&#039;t get even, get ahead!Thu May 01 1997 11:0836
>>                      <<< Note 2170.4 by CUJO::SAMPSON >>>
>>                -< with DECnet/OSI, NET$CONFIGURE should work >-

Bob,

I don't meant to ignore your suggestions, but it seems to me that
having to manually change these logicals AFTER running the 
UTC$CONFIGURE.COM is not quite right.  And, I really do want
to understand how it is supposed to work, and try to determine
if it's not working correctly.

FWIW, the only *time* logicals that I have on my system are
sys$localtime and sys$timezone_differential.  Does this indicate
that there's something wrong with my configuration?

Also, I have tried just changing the sys$timezone_differential logical,
and that alone does not make a difference in the tm_gmtoff value that
is returned.  And, I just ran a test while dtss was active.  First,
it wouldn't let me change the tdf without also changing the local
time.  Then, when I did change both, I saw the change to tdf reflected
in the sys$timezone_differential logical.  I didn't have to change
it.  Even with this, though, I still got the same value for
tm_gmtoff.

One other thing that I THINK is am seeing is that changing the TDF
value while dtss is active results in the sys$timezone_differential
logical also being changed.  Changing it while dtss is NOT active
does not have an effect on the logical.  Regardless, neither seem
to have an effect on the tm_gmtoff value.  

I'm considering elevating this because I think it's not working correctly.
Can someone please tell me how it's supposed to work?

Thanks,

Jerry
2170.7time to move?CUJO::SAMPSONThu May 01 1997 23:2516
    Jerry,
    
    Maybe at this point the discussion has more to do with OpenVMS and
    DECnet/OSI, a.k.a. DECnet-Plus, than it has to do with the DEC C RTL.
    
    So, maybe it's time to move it over to VMSNOTES or one of the
    DECNET-OSI conferences.
    
    From what I've seen, everything seems to work just fine with DEC C
    V5.5, OpenVMS V7.1, and DECnet-Plus V7.1, once NET$CONFIGURE menu
    item [5] has been done.  You get the four SYS$TIMEZONE* logicals,
    and DTSS maintains them.  I haven't done any extensive testing,
    though, and I haven't dealt with older versions much.
    
    HTH,
    Bob Sampson
2170.8first things firstCSC32::J_HENSONDon&#039;t get even, get ahead!Fri May 02 1997 11:2718
>>                      <<< Note 2170.7 by CUJO::SAMPSON >>>
>>                               -< time to move? >-

    
>>    Maybe at this point the discussion has more to do with OpenVMS and
>>    DECnet/OSI, a.k.a. DECnet-Plus, than it has to do with the DEC C RTL.
>>    
>>    So, maybe it's time to move it over to VMSNOTES or one of the
>>    DECNET-OSI conferences.

My main concern/question has to do with the DEC C RTL function localtime,
and whether or not it's behaving correctly.  If someone (as in someone
from DEC C RTL engineering) can assure me that this function is
behaving correctly, or that it's seemingly wrong behavior is due
to something else, I'll agree.  For now, though, all I want to know
is what value should localtime be returning for the tm_gmtoff item.

Jerry
2170.9our answerTLE::BORISBoris Gubenko, DEC C RTLSat May 31 1997 01:3093
  The question in the base note about connection between Time Differential
  Factor and tm_gmtoff member of the tm structure was elevated to IPMT case
  (HPAQ50GGH). Since the question was asked first in this public forum, we
  condider appropriate to post our update of the case here.

  Boris
  --------------------------------------------------------------------------
  We apologize for not getting to this IMPT case sooner.

  While

	"It seems reasonable the the tm_gmtoff value be the same as the TDF
	 value",

  this is correct only if the Time Differential Factor (TDF) has the value
  which matches time zone information used by the CRTL.

  The localtime() CRTL function accept "a pointer to a time in seconds since
  Epoch". The "time in seconds since Epoch" is usually obtained via the call
  to time() CRTL function, as in the test program in TURRIS::DECC, note 2170,
  the note that has started this discussion.

  It should be understood, that the "time in seconds since Epoch" has nothing
  to do with TDF set on a particular system or with time zone information
  used by the CRTL. This is just "the number of seconds elapsed since 00:00:00
  UTC Jan 1970".

  From the description of time() function:

	Returns the time (expressed as Universal Coordinated Time) elapsed
	since 00:00:00 January 1, 1970 in seconds.

  The localtime() function can be thought of as:

	. calling tzset() function to read and interpret appropriate binary
	  timezone file

	. calculating UTC time according to the "number of seconds elapsed
	  since Epoch" passed as a parameter

	. mapping UTC time obtained to a local time using the timezone
	  information set by tzset()

  Both tzset() and localtime() functions have no idea about UTC support
  mechanism on OpenVMS. They have no idea about such VMS inventions as
  SYS$TIMEZONE_DIFFERENTIAL logical or @UTC$CONFIGURE_TDF.COM command file.

  These functions, along with other time-zone supporting stuff, originate from
  the public domain software used on a number of systems including DIGITAL UNIX.

  Timezone information set by tzset() and used by localtime() is derived solely
  from the binary timezone file referred to by the TZ environment variable (or
  by SYS$LOCALTIME logical if TZ variable is absent from the environment).

  Binary timezone files shipped with OpenVMS are built using the ZIC compiler
  from timezone source files from the public domain.

  So, broken-down local time expressed as a tm structure is calculated for a
  given "number of seconds since Epoch" based solely on information from the
  currently used timezone binary file.

  This is why the change in TDF does not affect the value of tm_gmtoff.

  The bottom line is: TDF and TZ variable (or SYS$LOCALTIME logical, the
  default if TZ is not defined) must match. This is why @UTC$CONFIGURE_TDF.COM
  command file should be executed each time when, according to timezone rules,
  the time switches from standard time to daylight saving time and vice versa.

  Example below illustrates how the tm_gmtoff member changes with the change
  in timezone setting. The test program from TURRIS::DECC, note 2170 was used
  (note, that both values of the TZ variable imply that the current time is
  a daylight saving time).

  Boris Gubenko, DEC C RTL

$ TZ = "PST8PDT7,M4.1.0,M10.5.0"	! DST offset is set to 7 hours
$ r GETLT
The current time is: Thu May 29 14:03:36 1997

localtime returned the following
tm_hour = 14
tm_isdst = 1
tm_gmtoff = -25200
tm_zone = PDT
$ TZ = "PST8PDT-7,M4.1.0,M10.5.0"	! DST offset is set to -7 hours
$ r GETLT
The current time is: Fri May 30 04:03:56 1997

localtime returned the following
tm_hour = 4
tm_isdst = 1
tm_gmtoff = 25200
tm_zone = PDT