[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

2070.0. "mktime, time question" by CSC32::J_HENSON (Don't get even, get ahead!) Fri Jan 24 1997 16:38

dec c v5.3-002, ovms v6.2, alpha

I just finished talking to a customer who is claiming that the mktime
function is not working properly on ovms v6.2.  He is reaching this
conclusion by comparing the results he gets from the same function
on OpenVMS V6.1.  On Ovms v6.1, when he passes the date 12/31/67 to
mktime, he gets some negative number.  He is interpreting that as
the correct answer, since there is a negative number of days since
Jan. 1, 1970.

On ovms v6.2, using the same date yields a -1.  His conclusion is that
mktime is broken on ovms v6.2.

According to note 578 in turris::decc_bugs, a bug was fixed in the
rtl for "the next major version after V6.1" with mktime.  The bug
is that mktime was NOT returning a -1 for dates prior to 1970.
So, it appears that there is a misunderstanding of how mktime is
supposed to work.  I have already pointed this out, with the caveat
that I need to verify this to be correct.

So, I have two questions.

First, is it indeed the correct behavior for mktime to return a -1
for dates prior to 1970?  If so, is the per ansi standards?

Second, if this is the case, how about updating the rtl reference manual
for both mktime and time to reflect this.  

Thanks,

Jerry
T.RTitleUserPersonal
Name
DateLines
2070.1no negative numbersTAVENG::BORISBoris Gubenko, ISESun Jan 26 1997 10:38119
> So, I have two questions.
> 
> First, is it indeed the correct behavior for mktime to return a -1
> for dates prior to 1970?  If so, is the per ansi standards?
> 

  The mktime() functions returns (time_t)-1 if the local time passed
  cannot be represented by an object of type time_t.

  The question, actually, is: what range of the calendar times can be
  represented by an object of type time_t and this is implementation
  dependent.

  From ANSI C standard:

	Section 4.12.2.4 The time Function

	Synopsis

		#include <time.h>
		time_t time(time_t *timer);

	Description

	The time function determines the current calendar time. The encoding
	of the value is unspecified.

	Returns

	The time function returns the implementation's best approximation to
	the current calendar time.

  In the description of the mktime() function, the ANSI C states:

	The mktime function returns the specified time encoded as a value
	of type time_t. If the calendar time cannot be represented, the
	function returns the value (time_t)-1.

  On OpenVMS V6.2, the DEC C RTL's "best approximation to the current calendar
  time" (the object of type time_t) is the number of seconds elapsed past the
  Epoch.

  This definition is consistent with XPG4, which states in the description
  of the time() function:

	The time() function returns the value of time in seconds since the
	Epoch.

  Since the Epoch is defined as January 1, 1970, on OpenVMS V6.2 and higher
  the mktime() is supposed to return -1 for dates prior to 1970.

> Second, if this is the case, how about updating the rtl reference manual
> for both mktime and time to reflect this.
> 

  From Section 11.2 Overview of Date/Time Functions in the DEC C RTL Reference
  Manual, AA-PUNEE-TK, DEC C version 5.2:

	In the UTC-based model, times are represented as seconds since the
	                                                         ^^^^^
	Epoch. The Epoch is defined as the time 0 hours, 0 minutes, 0 seconds,
	January 1, 1970 UTC.


  From the description of the time() function in the Manual:

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


	Return Values

	x		The time elapsed past the epoch
                                 ^^^^^^^^^^^^

  From the description of the mktime() function in the Manual:

	Converts a local-time structure into time since the Epoch.
                                                  ^^^^^

	The function converts the local-time structure, ..., to a time in
	seconds since the Epoch in the same manner as the values returned
	by the time function.

	Return Values

	x		The specified calendar time encoded as a value of type
			time_t.

	(time_t)-1	If the local time cannot be encoded.


  In addition, the Manual mentions in the description of both the time() and
  mktime() functions, that DEC C RTL defines time_t type in the <time.h> header
  as UNSIGNED type, as follows:

	typedef unsigned long int time_t;

  It is clear, that with the unsigned type, it is impossible to distinguish
  between the number of seconds before the Epoch (which is supposed to be
  negative) and the number of seconds after the Epoch (which is supposed to be
  positive).

  It seems to me, that DEC C RTL Reference Manual makes it clear, that a time
  prior to the Epoch cannot be represented by a time_t object and, therefore,
  the mktime() function should return (time_t)-1 when passed such a time.

  There is also an upper limit for the date-time which can be passed to the
  mktime(). As mentioned in the Manual in the description of the mktime()
  function, the (time_t)(-1) also represents a valid date of

	Sun Feb 7 06:28:15 2106.

  So, the range of valid arguments for mktime() is:

	Jan 1 00:00:00 1970 <= date-time < Feb 7 06:28:15 2106
  
  Boris
2070.2Use LIB Routines...XDELTA::HOFFMANSteve, OpenVMS EngineeringMon Jan 27 1997 09:5610
    
    I'd use the time formatting services available in the LIB run-time
    library -- they handle this and many other formats, as well as
    different languages and user-level and system-level time format
    customizations.
    
    The UNIX and C time storage format (`epoch') runs from 1970 to 2038. 
    
    The OpenVMS time format supports 1858 to the thirty-second millenium.