An off-the-wall question:

time() returns a time_t, localtime() converts this to a struct tm with
local time values, gmtime() converts this to a struct tm with GMT values,
mktime() converts this back to a time_t, but _which_ struct tm does
it convert back?

i.e.,

time_t t0 = time(NULL);

struct tm T1 = *localtime(&t0);
struct tm T2 = *gmtime(&t0);

time_t t1 = mktime(&T1);
time_t t2 = mktime(&T2);

Either t0 == t1 or t0 == t2, but which is true?

Does the standard specify?
If so, how many compilers get it right?

--
    Nearly every electrical engineer believes deep in his heart that he
is better at writing computer software than any computer programmer,
and can show as proof the fact that he has written a number of small
applications, each of which was done quickly, easily, and exactly met
his needs.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

In article <4fovvr$f1d@blackice.winternet.com> jdege@winternet.com (Jeff
Dege) writes:

>     An off-the-wall question:
>
> time() returns a time_t, localtime() converts this to a struct tm with
> local time values, gmtime() converts this to a struct tm with GMT values,
> mktime() converts this back to a time_t, but _which_ struct tm does
> it convert back?

According to ISO 9899 (included by reference in the C++ standard): "The
mktime function converts the broken-down time, expressed as
_local_time_..."  (Emphesis added.)

> i.e.,
>
> time_t t0 = time(NULL);
>
> struct tm T1 = *localtime(&t0);
> struct tm T2 = *gmtime(&t0);
>
> time_t t1 = mktime(&T1);
> time_t t2 = mktime(&T2);
>
> Either t0 == t1 or t0 == t2, but which is true?

t0 == t1.

> Does the standard specify?
> If so, how many compilers get it right?

Given that this is a standard C function, and has been around for a
while, I would imagine that all of them do.  Particularly as the
function author has to make a choice in the matter, and there is no
particular motivation for a wrong choice.

More problematic is using mktime to correct the time, which it also
supports.  For example:

    time_t          t0( time( NULL ) ) ;
    struct tm       t = *localtime( &t0 ) ;
    t.tm_min += 60 ;
    mktime( &t ) ;

The last call to mktime should `correct' t so that the struct contains
the correct entry for the time one hour after that returned by time.  I
often wonder how well this has been tested, say when the original time
was 10 minutes before midnight Dec. 31, or before a change in time due
to switching between summer time and winter time.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

    This may not be needed, but the definition of 'tm' I was using
was the documentation associated with a particular implementation.
If the standard itself does not actualy specify a range,  I
appologize for the phrasing.  However, the issues behind each item
remain.

        Max
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

gsez020@nemo.bedford.waii.com (Pete Forman) wrote:
>
>My documentation (IRIX 6.1) gives the range as 0-61.  I presume that
>the current standard does cover leap seconds and that your copy is out
>of date.  I don't understand why it's not 0-60, though.

    As noted elsewhere, I was relying on the documentation that went
with a particular implementation.  I have since found other references
that make it clear that his has already covered.  The reason it is 0-61
is because there is a possibility that two leap seconds may be needed at
some future time.

>Your remaining points have little relevance.  localtime() and friends
>are indeed only useful for the Gregorian calendar.  If you were to try
>to extend to other calendars you would have difficulty specifying the
>rules.  Days may start at dusk, months according to observations of
>the moon.  Programs can only approximate the future and look up the
>past.

    The point is that the current phrasing DOES restrict the standard
to the Gregorian calendar.  I think a little judicious rephrasing might
allow the standard to be used by cultures that do not use the Gregorian
calendar.  The required change might be as simple as noting that the
ranges and definitions apply to the Gregorian calandar and that other
comprable ranges and definitions may be used in locales that use other
calendars.  This would permit but not require other calendar
implementations.

        Max
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Max TenEyck Woodbury wrote:
>
>     The C++ standard incorporates the C standard for dates and times
> by reference.  There are at least three problems with the 'struct tm'
> definition in that standard.
> ...
>     Second, there are cultures that operate on a lunar calendar,
> rather than on the Gregorian calendar.  They have 13 or more months
> a year.  The tm_mon range needs to reflect this.
>
>     Third, there are cultures that do not start their year on January
> 1st.  This has an impact on the definition of tm_yday even though
> its range will not change.  There is a similar definitional problem
> with tm_year. ...

The C++ Library (Draft!) standard is not as restrictive
as Woodbury suggests.  It is capable of representing
Gregorian dates, but does not in any way enforce them.
It does expect that any other date is convertible into
a Gregorian date (and a Julian), but that's a much weaker
restriction.

Nathan Myers
ncm@cantrip.org   http://www.cantrip.org/    <-- works now.

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

Bill Spitzak wrote:
>
>...
>
> Who says that other culture uses things called "months" or "seconds"
> or "hours", etc.
>    I am not an expert on this, but from what little I know the divisions
of a day into "hours" and "minutes" seems to be fairly uniform across
cultures.  The scientific comunity seems to have a uniform definition of
second as well.  "Months" are more problimatic but many cultures have a
time unit of roughly the length of the lunar cycle.  The Gregorian calandar
seems to be the worst approximation in that regard.  If you had asked about
"weeks" however, I'd be pretty much lost.
>
> Perhaps the structure should have been called
> "eurocentric_white_opressor_time_t" to more correctly reflect it's
> purpose?
>

    Only if you REALY insist, but I'd still object :-).  "moderately_general_
time_conversion_t" was what I was trying for.

> Seriously, these attempts at PC-correctness I think are insluting to
> the societies involved.  Are they too stupid or primitive to cram
> another value in the field, or to make up their own structure, without
> our benevolent guidance?
>

    This is SUPPOSED to be an INTERNATIONAL standard and the current phrasing
REQUIRES certain interpretations of these fields.  An acknowledgement that
locales other then "C" can redefine the precise meaining of some of the fields
would allow broader application without having to get exemptions for what is
obviously the "correct thing to do".

    The problem is not, as you imply, that people are stupid or primitive, but
that standards, by their nature, are narrow minded and literal.  As currently
phrased, reinterpreting these fields is not allowed no matter what local is
in control of time.  Now THAT is insulting.


        Max

[ To submit articles: Try just posting with your newsreader.  If that fails,
        use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

    The C++ standard incorporates the C standard for dates and times
by reference.  There are at least three problems with the 'struct tm'
definition in that standard.

    First, the range specified for tm_sec is 0-59.  While this is the
normal range for almost all minutes, there are officially 'leap
seconds' that are declared from time to time.  The standard should
reflect this possibility, even if it is almost always ignored in
practice.

    Second, there are cultures that operate on a lunar calendar,
rather than on the Gregorian calendar.  They have 13 or more months
a year.  The tm_mon range needs to reflect this.

    Third, there are cultures that do not start their year on January
1st.  This has an impact on the definition of tm_yday even though
its range will not change.  There is a similar definitional problem
with tm_year.

    There may also be a problem with tm_wday.  I vaguely remember
hearing about cycles of 17 or 19 days used in some cultural contexts
that might have been in addition to or in place of the weekly cycle,
but I can not remember the exact context.

        Max
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>>>>> "Max" == Max TenEyck Woodbury <mtew@cds.duke.edu> writes:

    Max> First, the range specified for tm_sec is 0-59.

My documentation (IRIX 6.1) gives the range as 0-61.  I presume that
the current standard does cover leap seconds and that your copy is out
of date.  I don't understand why it's not 0-60, though.

Your remaining points have little relevance.  localtime() and friends
are indeed only useful for the Gregorian calendar.  If you were to try
to extend to other calendars you would have difficulty specifying the
rules.  Days may start at dusk, months according to observations of
the moon.  Programs can only approximate the future and look up the
past.
--
Pete Forman
Western Geophysical
pete.forman@bedford.waii.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]