🚀 go-pugleaf

>>>>> "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. ]

    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. ]

In article <tuivhsd7fn.fsf@nemo.bedford.waii.com>
gsez020@nemo.bedford.waii.com (Pete Forman) writes:

|> >>>>> "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.

A bug in the C standard:-).  This was discussed some time back on
comp.std.c.  If I remember correctly, the correction from 0-59 was
made at the last minute.  It was pointed out that there had even been
a year with two leap seconds, so they made provision for two leap
seconds:-).  Of course, with a maximum of two leap seconds per year,
no one is going to put them in the same hour.

|> 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.

Agreed.  There is a package on the net somewhere that will handle all
of the other time systems, though.  Or so I have heard.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité 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
  summarized in http://reality.sgi.com/employees/austern_mti/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
]

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. ]