Carsten Isert wrote:

> So I was wondering if there is any Time class out there, that I can
> use so that I don't have to write anything on my own, as this should
> be some code which is used fairly often.

Also, I would be curious to know what role the time category defined
by the Standard would affect and interact with such a class.

Eric.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Eric Lemings <eric.b.lemings@lmco.com> wrote:
>Carsten Isert wrote:
>
>> So I was wondering if there is any Time class out there, that I can
>> use so that I don't have to write anything on my own, as this should
>> be some code which is used fairly often.
>
>Also, I would be curious to know what role the time category defined
>by the Standard would affect and interact with such a class.

It would provide internationalized i/o formatting and parsing for
the Time object, given trivial definitions of operators << and >>
for the Time class.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Bill Wade" <bill.wade@stoner.com> writes:

|>  A quality implementation of mktime will let me find "same time tomorrow", by
|>  adding one to the "day" field of tm (and counting on mktime to adjust month
|>  and year if necessary).  It also gives me the tools to determine if that
|>  time is ambiguous (01:30 occurs twice tomorrow) or non-existent (there is no
|>  01:30 tomorrow).

In this case, you should replace "quality implementation" by "conforming
implementation".  This behavior is required by the C standard.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

In article <34B4E872.3E2C447C@physik.tu-muenchen.de>, celtschk@physik.tu-
muenchen.de says...
> For example: What does it mean to add one month? Well, it depends.
> In April it means adding 30 days, in March it means adding 31 days, and
> in February, it may be 28 or 29 days, depending on the year.

of course, some of us would also argue that the only real way to do
months is to do the lunar orbital calculations, and forget about rounding
things to days.

stuart
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Followup to:  <34B4E872.3E2C447C@physik.tu-muenchen.de>
By author:    Christopher Eltschka <celtschk@physik.tu-muenchen.de>
In newsgroup: comp.std.c++
>=20
> Exactly here I see the main problem:
> You would have to invent a way to represent time differences. But time
> differences are not always well defined.
>=20
> For example: What does it mean to add one month? Well, it depends.
> In April it means adding 30 days, in March it means adding 31 days,
> and in February, it may be 28 or 29 days, depending on the
> year. That is, you can't simply translate a time difference of one
> month into a fixed number of days, seconds, microseconds, or
> whatever - the exact value depends on the date when you do it. Now
> consider the different direction: How long is it from Jan. 1, 1994
> to Feb. 2, 1995?  Well, it's 1 year, 1 month and 1 day. Or it's
> 366+31+1=3D398 days (leap year!).  Those two time differences are
> indeed different: If you apply the first one to Jan. 1, 1995, you
> get Feb. 2, 1996; applying the second one results in Feb. 3, 1996!
>=20

I think one has to distinguish "true" time intervals (mesurable in
seconds) from clock/calendar intervals, which aren't -- they have more
the aspect of an algorithm than a time interval.

 -hpa
--=20
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah=E1'=ED -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Mis=E9rable=
s
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Bradd W. Szonye wrote:
>
> Okay, so add me to the list of people who aren't happy with the time
> facilities. I'll just reinvent the wheel when I need to work with times.
> (Maybe I'll get rich in the next five years, or start working for a company
> who'll want to send me to ANSI. A good time subsystem is one of the things
> I'd tentatively be willing to champion, if I could get my foot in the door.
> Unfortunately, I can barely afford an Observer's price of admission, let
> alone bear the expense of actually attending meetings as a Participant.)

The most important step in getting a proposal accepted into the language
is to create the proposal. Posting messages that say "I don't like this"
doesn't accomplish that. Design a better solution, implement it,
evaluate it. Repeat until done. Then propose it.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Stephen Cipolli wrote:

[...]

> 8. IMO, any time/calendar facility must minimally provide addition,
> subtraction and relational operations.

Exactly here I see the main problem:
You would have to invent a way to represent time differences. But time
differences are not always well defined.

For example: What does it mean to add one month? Well, it depends.
In April it means adding 30 days, in March it means adding 31 days, and
in February, it may be 28 or 29 days, depending on the year. That is,
you
can't simply translate a time difference of one month into a fixed
number
of days, seconds, microseconds, or whatever - the exact value depends on
the date when you do it. Now consider the different direction: How long
is it from Jan. 1, 1994 to Feb. 2, 1995?
Well, it's 1 year, 1 month and 1 day. Or it's 366+31+1=398 days (leap
year!).
Those two time differences are indeed different: If you apply the first
one to Jan. 1, 1995, you get Feb. 2, 1996; applying the second one
results
in Feb. 3, 1996!

So, what should be the correct result of

  time("Jan 1, 1995") + ( time("Feb 2, 1995") - time("Jan 1, 1994") ) ?

Surely, some would be dissatisfied with time("Feb 2, 1996"), while
others
would be dissatisfied with time("Feb 3, 1996").

I see three possible solutions:

1. Demand one single interpretation of time differences (probably the
one
   that is easiest to implement), and leave the other people
unsatisfied.
   Alternatively, implement the other methods as function calls.
2. Make time and time_difference templates, with a traits template
parameter
   indicating the way time differences have to be calculated/applied,
similar
   to the implementation of strings.
   The disadvantage is that you wouldn't be able to assign one type to
the
   other despite the same representation, just because the differences
should
   be calculated differently, as they are unrelated types.
3. Use a locale-like implementation to decide which way time differences
have
   to be treated. In this case, the only implementation of
time_difference
   which would not limit you in interpreting time differences would be
to
   store the two times subtracted themselves, together with a pointer to
the
   "locale" to be used for the difference. Only this way, you can be
shure
   that every time difference description you invent can be represented
   (f.ex. the difference in seconds needs one number; the difference in
   years/months/days/hours/minutes/seconds needs six numbers. OTOH, each
   difference of each difference description must be uniquely determined
   by the two times, so the times plus the method fully determine the
   difference)

Version 3 is IMHO the most flexible one, as it allows to defer the
desicion
how the difference has to be calculated until run time. It can even
allow to
select another type of difference after it has been "calculated":

time time1, time2, time3;

set_time_difference_type(td_seconds);
   // use seconds as default time difference description

time time4 = time1 + (time2 - time3);
   // use default difference (i.e. seconds)
time time5 = time1 + (time2 - time3).set_difference_type(td_ymdhms);
   // use years/months/days/hours/minutes/seconds difference description

Of course, if the time type itself is templated (to allow different
representations), the time_difference must be templated as well. The
easiest way would be the time type as template parameter.


Another problem of the time library would be the correct division
between representation and calendar. On the first view, they are
quite separated - the time itself is completely independant of how
we write them. OTOH, the calendar comes into play in cases where
you calculate differences. You can't tell the meaning of "adding
one month" without referring to the calendar (as seen above). So
the calendar influences at least the time_difference.

Also the localisation breaks down into two parts: There's the calendar
used, and then the textual representation of the dates of the calendar
(That is, you can express the date as Jan 8, 1998, as 1/8/98, or
January 8, 1998; in Germany those options would be 8. Jan. 1998, 8.1.98
and 8. Januar 1998; etc. ). The calendar itself is mostly independent
of the locale (the Gregorian calendar is the same in all countries,
f.ex.; only the default calendar may be a different one in different
countries), therefore IMHO it should not get into the normal locale
library, but be independent. The textual representation
("January"/"Januar",
"Jan 8, 1998"/"1/8/98" etc.) of course belongs into the locale library.
OTOH, the textual representation depends heavily on the calendar used,
so this would be a strong argument to embed the calendar in the locales.

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

References: <2.2.32.19971203011117.00357010@central.beasys.com>
            <68sq59$kct@examiner.concentric.net>

Pete Becker <petebecker@acm.org> wrote:
> Bradd W. Szonye wrote:
> >
> > Okay, so add me to the list of people who aren't happy with the time
> > facilities. I'll just reinvent the wheel when I need to work with times.
> > (Maybe I'll get rich in the next five years, or start working for a company
> > who'll want to send me to ANSI. A good time subsystem is one of the things
> > I'd tentatively be willing to champion, if I could get my foot in the door.
> > Unfortunately, I can barely afford an Observer's price of admission, let
> > alone bear the expense of actually attending meetings as a Participant.)
>
> The most important step in getting a proposal accepted into the language
> is to create the proposal. Posting messages that say "I don't like this"
> doesn't accomplish that. Design a better solution, implement it,
> evaluate it. Repeat until done. Then propose it.

I'd like to add that, in many cases, it's also very important that the
proposal be made in tandem to the ISO C committee.  Allowing the two
languages to drift too far apart isn't wise, and affects the portability
of data between the two.  I realize this doesn't always apply for C++
features being rolled into C, but it certainly applies the other way
around.

Inventing a new time class in C++ without providing a low-level
representation for the data which can implemented in C is a mistake.
For example, I'm working on a proposal for a 64-bit extended time
value that is a simple data type and a small set of library functions
for C.  In C++, one or more classes can then be built on top of this
underlying simple data type.  Once done, we then have the ability (or at
least a fighting chance) of porting extended time values between both C
and C++ programs.

(See <http://www.flash.net/~dtribble/text/c0xtime.htm>, but be warned
that it's only a rough working draft at the moment.)

-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Eric Ulevik" <eau@ozemail.com.au> writes:

|>  Bradd W. Szonye wrote in message <68p5jh$if8@examiner.concentric.net>...
|>  >It's a harmless but well-known bug
|>  >in the specification, one of the few that is identified for <ctime>. To fix
|>  >it, you would indeed lower the maximum to 60, to allow only one leap
|>  second.
|>
|>  Multiple leap seconds may be inserted if the earth's movement makes it
|>  desirable. If the standard allows leap seconds, it should allow multiple
|>  leap seconds.

It does allow for multiple leap seconds.  Just not in the same hour.

There is an international rule concerning this, I think.  Basically, a
leap second will only be inserted in the last hour of the last day of a
month.  We're currently averaging less than one a year.  As time passes,
the earths rotation speed slows down, and so the number of leap seconds
needed will increase.  Still, it will be literally millions of years
before we start needing even two in a single day.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

In article oj6@newshost.fujitsu.com.au, "Eric Ulevik" <eau@ozemail.com.au> writes:
>Bradd W. Szonye wrote in message <68p5jh$if8@examiner.concentric.net>...
>>It's a harmless but well-known bug
>>in the specification, one of the few that is identified for <ctime>. To fix
>>it, you would indeed lower the maximum to 60, to allow only one leap
>second.
>
>Multiple leap seconds may be inserted if the earth's movement makes it
>desirable. If the standard allows leap seconds, it should allow multiple
>leap seconds.

Although a given year can have more than one leap second, a given day
cannot have more than one leap second, on the time scale supported by
struct time_t. Thus, it is not necessary for struct time_t to
accomodate more than one leap second.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

"Bradd W. Szonye" <bradds@concentric.net> writes:

|>  Eric Ulevik wrote in message <68rpr9$oj6@newshost.fujitsu.com.au>...
|>  >
|>  >A good solution [to DST problems] is: do all calculations in UTC,
|>  >and only use local time for display.
|>
|>  But the only facility for time calculations is mktime(), which uses local
|>  time. Arithmetic on time_t values is verboten, and the means of setting the
|>  local time zone are implementation-defined. So unfortunately, there's no
|>  portable way to do time arithmetic without coping with the DST problems.

And even if there were, it's not what is wanted in every case.  When
someone says "same time, tomorrow", you can't just add 24*60*60 to the
system time (even supposing a Unix like seconds from the epoch).
Because usually, when someone says "same time, tomorrow", they are
thinking in terms of local wall clock time, and not in UTC.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

J. Kanze wrote in message ...
>"Bradd W. Szonye" <bradds@concentric.net> writes:
>|>
>|>  [There's no way] to do time arithmetic without coping with the DST
problems.
>
>And even if there were, it's not what is wanted in every case.  When
>someone says "same time, tomorrow", you can't just add 24*60*60 to the
>system time (even supposing a Unix like seconds from the epoch).
>Because usually, when someone says "same time, tomorrow", they are
>thinking in terms of local wall clock time, and not in UTC.

Right: time is one of those things where the "units" used matter to humans.
(I think I said something similar in another article recently.) Because the
length of a year, month, day, and even minute can differ (because of leap
days, variable length, DST, and leap seconds, respectively), it really makes
a difference whether you're asking for, say, +1 day and not just +24 hours
or +(24*60*60) seconds.

At the very least, I think there's some need to deal with times, dates, and
date-times separately because of this; how far exactly to go with this and
implementing the various "units" involved (weeks?) is debatable. Should the
standard library really care about the difference between 24 hours and 1
day, or should it just provide the hooks for application programs to make
this distinction?

As an example of what I mean by hooks: it might be enough for an application
to know that February contains 29 days in a given year or that the last
Sunday in October is only 23 hours long in some cases. The trouble is,
there's still a lot of "guesswork" involved, especially regarding difference
operators.

To answer Pete Pecker's valid criticism of my earlier griping: I feel more
confident in my ability to champion and influence someone else's proposal
than to make my own. This is one case where I feel more confident in my
ability to spot holes and plug them up than to come up with something close
to solid on my own. Therefore, I think that being able to influence the
decision-making is more valuable to me than to draft a complete proposal. My
main hope is that someone is able to come up with a workable draft in the
first place.
---
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Eric Ulevik <eau@ozemail.com.au> writes:

|> Bradd W. Szonye wrote in message <68p5jh$if8@examiner.concentric.net>...
|>> It's a harmless but well-known bug
|>> in the specification, one of the few that is identified for <ctime>. To fix
|>> it, you would indeed lower the maximum to 60, to allow only one leap
|> second.

|> Multiple leap seconds may be inserted if the earth's movement makes it
|> desirable. If the standard allows leap seconds, it should allow multiple
|> leap seconds.

But never in the same *minute*.  There will never be a time of hh:mm:61,
but there may be two occurences of hh:mm:60 in the same *year*.

--
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

J. Kanze wrote in message ...
>"Bradd W. Szonye" <bradds@concentric.net> writes:
>|>
>|>  But the only facility for time calculations is mktime(), which uses
local
>|>  time. Arithmetic on time_t values is verboten, and the means of setting
the
>|>  local time zone are implementation-defined. So unfortunately, there's
no
>|>  portable way to do time arithmetic without coping with the DST
problems.
>
>And even if there were, it's not what is wanted in every case.  When
>someone says "same time, tomorrow", you can't just add 24*60*60 to the
>system time (even supposing a Unix like seconds from the epoch).
>Because usually, when someone says "same time, tomorrow", they are
>thinking in terms of local wall clock time, and not in UTC.

It seems to meet that the current facilities come very close (and QOI issues
should close the gap) to meeting both requirements.

time_t must be an arithmetic type (at least in C and Posix, I haven't
checked C++) so arithmetic isn't verboten, it is just implementation
dependent.  If I assume time_t uses a linear (not, for instance logarithmic)
representation for time I can compute how much time_t corresponds to a
second.  Pseudo code:
  const time_t second =
    mktime("1997/01/09 08:42:56") - mktime("1997/01/09 08:42:55");
I can find the time 24 hours from now as
    time_t later = now + 24*3600*second;
I'll agree that it would be better to have an addtime() complement to
difftime(), and even better if I could directly ask my implementation what
range and precision it supported.

A quality implementation of mktime will let me find "same time tomorrow", by
adding one to the "day" field of tm (and counting on mktime to adjust month
and year if necessary).  It also gives me the tools to determine if that
time is ambiguous (01:30 occurs twice tomorrow) or non-existent (there is no
01:30 tomorrow).

There are certainly numerous problems with the current tools (most serious
IMO is the inability to easily handle multiple time zones).
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

In article <6932r4$rid@engnews1.Eng.Sun.COM>, clamage@eng.sun.com
says...

[ ... ]

> Although a given year can have more than one leap second, a given day
> cannot have more than one leap second, on the time scale supported by
> struct time_t. Thus, it is not necessary for struct time_t to
> accomodate more than one leap second.

Presumably you meant "struct tm" instead of "struct time_t" ?

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Pete Becker wrote in message <34A855E0.2B3B83B7@acm.org>...
>Stephen Cipolli wrote:
>>
>> >Pete Becker <petebecker@acm.org> writes:
>> >
>> As for "too late".  Things are only too late, if the committee says so and
>> even then I don't really understand what "too late" means.
>
>It means that the standard is finished, unless someone discovers a major
>technical error. Omissions of someone's favorite feature are not major
>technical errors.

I get the picture.  I will leave it go, but remember that one (wo)man's
feature is another (wo)man's omission.

---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

J. Kanze wrote in message ...
>"Stephen Cipolli" <stephen.cipolli@qed.net> writes:
>
>|> >Pete Becker <petebecker@acm.org> writes:
>|> >
>|> >>  Stephen Cipolli wrote:
>
>Well, I do contribute to AFNOR, and it does take a lot of time and
>effort.  And my contributions are nothing compared to what some others
>are doing.

I commend and thank everyone who has worked on the C++ (draft) standard.

>And the analogy with car makers doesn't hold.  First, because you pay
>hard cash for a car -- you don't pay anything for the standard to
>exist.  And more importantly, because, as you say, the car makers don't
>give you a chance to intervene, before or after.  You take what they
>make, or you walk.  In the case of the standard, there is a more or less
>democratic process, and you can influence it.  If there had been a
>concrete proposal for a time/calendar class, I'm sure the committee
>would have considered it.  If it had been good, covering most of the
>issues, not breaking anything else in the library, and fitting in with
>the rest of the library (particularly iostream), I rather think that it
>would have been accepted.

You are asking the people who use or are going to use, compilers developed
to the specification of the standard to get their feedback to the committee
even before a final draft has been ratified.  Users will only be able to
provide feedback when implementations reasonably represent the state of the
draft/standard, because that is when they have the opportunity to bring
themselves up-to-date.  This usually happens a year too late.

>|> As for the idea that this is important only to me and therefore I should
>|> have pursued this earlier.  I can easily build any kind of time/calendar
>|> classes I desire to satisfy my own requirements (as much as I hate to waste
>|> time doing it).  The problem is important to _all_ users, since each will
>|> have to "reinvent the wheel" and will do so in incompatible and perhaps
>|> incorrect ways.  The problem is not personal, it is (or will be) pervasive.
>|>
>|> As for "too late".  Things are only too late, if the committee says so and
>|> even then I don't really understand what "too late" means.
>
>In this case, "too late" means too late.  The committee doesn't work in
>a vacuum; it obeys ISO rules.  And the ISO rules say that, having
>presented an FDIS (Final Draft International Standard) for approval, no
>changes in the technical content are allowed.
>
>But then, I think that this is all explained in the comp.std.c++ FAQ.

If you read the rest of my paragraph, you would have noticed that I was
pointing out that changes could be incorporated at any point along the
time-line at whatever version by whatever rules ANSI/ISO specifies.
And regardless, the committee _does_ have the option to postpone (albeit
with ramifications) the process to correct problems.  I understand that you
and others think that the time/cal problem does not warrant such a
postponement, but the option does exist.  FAQ or no FAQ.

>Maybe you don't have the time or the opportunity to read that, either.

To what "that" are you referring.   Are you implying that I have not _read_
the draft standard.  I have read several public versions of the drafts in
whole or in part over the last 7 years (although obviously not in the time
frames this committee requires to make comments).  I have not _reviewed_
(commented on) or made proposals for such drafts for this committee, as I
have cited.

>|> Is the committee
>|> going to wait until the draft is completely ratified before considering
>|> proposals for a next version of the standard or does the committee believe
>|> that this is going to be the one and only version?
>
>Again, read the FAQ.  The committee is required by ISO procedure to make
>no changes at present.  They are also required to consider a new version
>no later than five years after the current version has been formally
>adopted.

Again, the committee can postpone (at a cost).  I'm sure that you and others
do not want to consider such an option, but the option exists nonetheless.
Also, starting the process of version 2 of the standard is not _ratifying_
version 2 of the standard.  It is getting beyond: "We can't consider
changes" .
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

"Bradd W. Szonye" <bradds@concentric.net> wrote:
>time between revisions is intended to be approximately five years

Actually, "minimum" five years.

>"Too late" means that no proposals can be accepted without delaying the
>initial release of the standard by 12 to 24 months.

Almost certainly 24.

>Currently, C++ is a
>Final Draft International Standard; by ISO rules, the FDIS will be either
>ratified (possibly with minor editorial changes) or not. If not, the
>standard returns to national standards bodies (like ANSI) for review and
>corrections, a process which takes over a year.

(Note that not being ratified is utterly unlikely and would be a horrible
disaster. The voting countries were unanimous, and all countries' CD2
comments were resolved to everyone's satisfaction.)

However, to be specific: If somehow it's not ratified we still wouldn't
know until March, it would then take at least one or two meetings after
that (4 or 8 months) to come up with another CD, and another 12 months
after that to get to the point where we are now (just like it took 12
months from the CD2 release to the FDIS release). That's two extra years.

>"Too early" means that the C++ committee will not convene again for at least
>three years to consider even whether the standard will be revised. They
>accept no proposals until after that determination is made.

The committee will still be meeting regularly, only probably less often
than three times a year (the schedule is undecided, but twice a year seems
likely). That's where DR, TC, and NA work is done:

>In the meantime, the committee "merely" answers complaints by issuing Defect
>Reports, Technical Corrigenda, and Normative Amendments (in order of
>increasing impact and decreasing likelihood). In layman's terms: a Defect
>Report states clarifications or acknowledges problems; a Technical
>Corrigendum corrects more substantial problems identified in the Defect
>Reports, usually in large batches; a Normative Amendment contains major
>corrections and additions to the standard.

Right, and essentially these should(?) be limited to defects and not
major/new enhancements. No enhancement proposals should be considered for
five years. (There may be a little room for interpretation here: Is the
lack of hash table-based containers a defect or an enhancement? :-) )

>>I think the user
>>community would be better served by not trying to "put the brakes on"
>>changes.  Accept or reject whether a problem exists and if it does exist,
>>start working out the solution.  When or what version of the standard it
>>gets rolled into is of much less importance.

The people who have been watching/working on this for eight years might
disagree... :-)

>At this point, the "user committee" needs a language standard more than
[any particular feature]

That, indeed, is the bottom line.

>>I'd like to hear simple answers to the question:
>>Is the current draft's handling of time/calendar adequate for the C++
>>community?
>
>I must reluctantly answer: yes, it is adequate, although no more than
>adequate.

Yes, for a different reason: All national bodies agreed that the FDIS was
adequate. By implication, all national bodies unanimously agree that the
time facilities are adequate. :-)

See also this newsgroup's FAQ, and my column in the January 1998 C++
Report which is entirely about the past, present, and future of the C++
standardization process.

---
Herb Sutter (mailto:herbs@cntc.com)

Current Network Technologies Corp.     2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com        Mississauga Ontario Canada L5K 2N6
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Followup to:  <m33ejnzns3.fsf@gabi-soft.fr>
By author:    kanze@gabi-soft.fr (J. Kanze)
In newsgroup: comp.std.c++
>=20
> To which I might add that the C standards committee has just issued a
> CD, and as far as I know, there are no modifications to the time
> handling (except maybe correcting a few small errors, such as allowing
> tm_sec to have a maximum of 61 instead of 60).
>=20

You mean the other way around, no?

 -hpa
--=20
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah=E1'=ED -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Mis=E9rable=
s
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

hpa@transmeta.com (H. Peter Anvin) wrote:
>kanze@gabi-soft.fr (J. Kanze)
>> To which I might add that the C standards committee has just issued a
>> CD, and as far as I know, there are no modifications to the time
>> handling (except maybe correcting a few small errors, such as allowing
>> tm_sec to have a maximum of 61 instead of 60).
>
>You mean the other way around, no?

I don't know about the change James is talking about, but I assume it's
probably to accommodate leap seconds.

---
Herb Sutter (mailto:herbs@cntc.com)

Current Network Technologies Corp.     2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com        Mississauga Ontario Canada L5K 2N6
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

herbs@cntc.com (Herb Sutter) writes:

|>  (Note that not being ratified is utterly unlikely and would be a horrible
|>  disaster. The voting countries were unanimous, and all countries' CD2
|>  comments were resolved to everyone's satisfaction.)

For an appropriate definition of satisfaction:-).  At least in the case
of France (and I hope I'm not misrepresenting the general opinion I
sensed at the last AFNOR meeting), I don't think that the word
"satisfaction" would really describe our feeling.  About the best one
can say is that having the current draft as a standard is light-years
better than not having any standard at all.  I can live with the current
draft, and I cannot really continue without a standard -- it's been way
too long already.

    [...]
|>  Yes, for a different reason: All national bodies agreed that the FDIS was
|>  adequate. By implication, all national bodies unanimously agree that the
|>  time facilities are adequate. :-)

Again, nobody voted saying that feature X was adequate.  All that was
voted was that any improvements in the feature were less important than
having a standard to begin with.  (That said, the fact that none of the
national bodies commented on the lack of adequacy in the time facilities
during the CD2 vote suggests strongly that they did feel that these
facilities are adequate, or at least, didn't have any concrete
suggestions as to how to improve them.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

hpa@transmeta.com (H. Peter Anvin) writes:

|>  Followup to:  <m33ejnzns3.fsf@gabi-soft.fr>
|>  By author:    kanze@gabi-soft.fr (J. Kanze)
|>  In newsgroup: comp.std.c++
|>  >=20
|>  > To which I might add that the C standards committee has just issued a
|>  > CD, and as far as I know, there are no modifications to the time
|>  > handling (except maybe correcting a few small errors, such as allowing
|>  > tm_sec to have a maximum of 61 instead of 60).
|>  >=20
|>
|>  You mean the other way around, no?

Yes.  The new range is [0...60], instead of [0...61].  (There is, at
most, one leap second per minute.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>>kanze@gabi-soft.fr (J. Kanze)
>>> correcting a few small errors, such as allowing
>>> tm_sec to have a maximum of 61 instead of 60

>hpa@transmeta.com (H. Peter Anvin) wrote:
>>You mean the other way around, no?

Herb Sutter wrote in message <34b0ab28.2248525148@nr1.toronto.istar.net>...
>I don't know about the change James is talking about, but I assume it's
>probably to accommodate leap seconds.

I think the defined range right now is 0-61, which accommodates up to two
leap seconds (the 60th and 61st second). It's a harmless but well-known bug
in the specification, one of the few that is identified for <ctime>. To fix
it, you would indeed lower the maximum to 60, to allow only one leap second.

What I think is more important to fix are the problems with DST boundaries.
It's been a while since I've looked closely at this problem, but you can run
into trouble when normalizing a 'struct tm' (with mktime()) in the vicinity
of a DST boundary. I think there are ways that you can end up with an
ambiguous or invalid time, starting from a valid time and a valid offset.
Unfortunately, the way the mktime() algorithm works isn't very clear on what
should happen, so it might be a QoI issue or not a problem at all. I can't
really tell. This is one place where having good time classes and overload
operators would help, especially in specifying intent: sometimes there's a
difference between adding 24 hours and adding a day.
---
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

herbs@cntc.com (Herb Sutter) writes:

|>  hpa@transmeta.com (H. Peter Anvin) wrote:
|>  >kanze@gabi-soft.fr (J. Kanze)
|>  >> To which I might add that the C standards committee has just issued a
|>  >> CD, and as far as I know, there are no modifications to the time
|>  >> handling (except maybe correcting a few small errors, such as allowing
|>  >> tm_sec to have a maximum of 61 instead of 60).
|>  >
|>  >You mean the other way around, no?
|>
|>  I don't know about the change James is talking about, but I assume it's
|>  probably to accommodate leap seconds.

Sort of.  As I understand it, the C committee originally had it right
(0...60, for a potential leap second).  But in the last minutes, some
one happened to mention that it was possible to have two leap seconds in
a year, and the range was hastely "corrected" to allow two leap seconds
-- in a single hour, which isn't possible (or at least, won't be for
millions of years).  The current modification simply drops the range
back to what it should be.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Bradd W. Szonye wrote in message <68p5jh$if8@examiner.concentric.net>...
>It's a harmless but well-known bug
>in the specification, one of the few that is identified for <ctime>. To fix
>it, you would indeed lower the maximum to 60, to allow only one leap
second.

Multiple leap seconds may be inserted if the earth's movement makes it
desirable. If the standard allows leap seconds, it should allow multiple
leap seconds.

>What I think is more important to fix are the problems with DST boundaries.


The problem is that there are invalid times (skipped when the clock moves
forward) and duplicate times (repeated when the clock moves back). Because
of this there is no linear conversion from UTC to local time.

A good solution is: do all calculations in UTC, and only use local time for
display.

Regards,

Eric Ulevik
eau@ozemail.com.au
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Eric Ulevik wrote in message <68rpr9$oj6@newshost.fujitsu.com.au>...
>
>A good solution [to DST problems] is: do all calculations in UTC,
>and only use local time for display.

But the only facility for time calculations is mktime(), which uses local
time. Arithmetic on time_t values is verboten, and the means of setting the
local time zone are implementation-defined. So unfortunately, there's no
portable way to do time arithmetic without coping with the DST problems.

Come to think of it, this is a more general shortcoming of the C approach to
timezones: the global nature of the "local" zone. C++ mostly fixed these
problems in the domain of locales in general, but there's still big holes in
the support for multiple time "locales."

Okay, so add me to the list of people who aren't happy with the time
facilities. I'll just reinvent the wheel when I need to work with times.
(Maybe I'll get rich in the next five years, or start working for a company
who'll want to send me to ANSI. A good time subsystem is one of the things
I'd tentatively be willing to champion, if I could get my foot in the door.
Unfortunately, I can barely afford an Observer's price of admission, let
alone bear the expense of actually attending meetings as a Participant.)
---
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

David R Tribble  <david.tribble@central.beasys.com> wrote:
>Nathan Myers wrote:
>> There are many possible "compact" representations for time and date
>> that represent different tradeoffs.  It may be that a future standard
>> should describe requirements for template parameters intended to
>> represent such types, rather than defining a particular type.
>
>A good starting point would probably be a 64-bit binary (long long int)

I'm afraid David's suggestion entirely misses the point.

Because there are conflicting requirements on time representations,
it would be a mistake to standardize a particular one in preference
to the rest.  An STL-like "Category" of types that represent timestamps
(in the sense that the Input Iterator category represents all iterators)
would provide the portability needed.  This way all the representations
that David listed, and also Java's time type, could be accommodated
without forcing unnecessary conversions.

Such a requirements list would not specify precision or range, just
the set of operations (in the form of valid expressions) that any
conforming type would support.  There would be a time_traits<> template
to describe precision & range, which would be specialized for each
actual time type.

This is not to say that such conversions between representations should
be impossible; indeed, a part of the requirements should be a prescribed
way to perform any conversions that are supported.

Probably there should be a separate type, for each representation,
to represent durations, because despite that the two uses are frequently
conflated they represent different concepts and should be distinguishable
in the type system.

>....  The
>Gregorian calendar should be employed (even though some countries used
>different calendars before its adoption).  Using a single calendar encoding
>gives a consistent and standard reckoning scheme.
...
>Even though the encoding has subsecond precision, leap seconds should not
>be encoded, because it complicates the encoding.

A count of time units (seconds, microseconds) since (or until) an epoch
has nothing to do with any calendar system.  Conversions to and from
a calendar representation are independent of such choices as range
and precision.  Certainly, whether to bother with leap seconds is part
of such a conversion and not of a time representation.

Probably the choice of whether to try to incorporate leap-seconds
into such a conversion should be left to those who request the
conversion, rather than second-guessed by a standards group.  An
estimate of the precision of the conversion ought to be part of
the result. E.g., for a time 1000 years in the future, the Gregorian
breakdown might be reported to be as much as 1000 seconds off, due to
expected leap seconds.

>...
>The new time type could be defined as a simple typedef, say, 'ltime_t'

The "_t" suffix is an historical "C-ism".  A typedef would be
a terribly grievous mistake, for any serious time representation,
because it would interfere with full use of the C++ type system.
A pair of structs (one for time, one for duration) containing
64-bit quantities, and provided with a full complement of operators,
would work better -- and would work on compilers that don't support
(or need) any "long long" extension.

Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <67ru5q$lol$1@shell7.ba.best.com>, ncm@nospam.cantrip.org
says...
> Subject: Re: Time class
> From: ncm@nospam.cantrip.org (Nathan Myers)
> Newsgroups: comp.std.c++
>
> David R Tribble  <david.tribble@central.beasys.com> wrote:
> >Nathan Myers wrote:
> >> There are many possible "compact" representations for time and date
> >> that represent different tradeoffs.  It may be that a future standard
> >> should describe requirements for template parameters intended to
> >> represent such types, rather than defining a particular type.
> >
> >A good starting point would probably be a 64-bit binary (long long int)
>
> I'm afraid David's suggestion entirely misses the point.

I've got to agree with you here. There is a range of prior art in time
representation, which should not be overlooked. There are clearly
interactions with:

* locale - different areas (and ethnic groups within those areas) use
different calenders in a manner analogous to the use of
language/character set.
* scientific computing - modelling sub-atomic particle interaction,
galactic lifetimes and differential time (i.e. the way the flow of time
depends on gravity).
* historical calendars - or does locale have a method of saying "the way
X ethnic group did things Y years ago" ?
* historical uncertainty about the exact conversions from calendar to
calendar.
* error handling - especially dates outside the calender range
* multi-threading - as others have discussed
* calenders which are not pre-determined - leap seconds, moving feasts,
arbitrary future changes made for social, political or economic reasons
etc.
* timezones
* social issues - if you're working at the millennium level, does the
millennium start at 0 or 1 ?
* drawing the lines between a calendar and holidays/events expressed in
that calendar, especially for historical calendars, where the calendar
is essentially defined in terms of the events.
* calendars which are defined in terms of enumerations rather than
numbers (for example the cycle of chinese animal years).

There are also certain aspects of calenders which amount to orbital
calculations (several calenders use real lunar months etc), where i'm
sure there's also a great deal of prior art which needs to be looked at
before jumping in.

I feel that there is probably a solution in terms of parameterised types,
but there'll be a powerful number of parameters, and a library supporting
many locales/uses is going to get VERY big. There is a good reason
calendars have been done wrong so many times in the past, because they're
hard.

stuart
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

On 24 Dec 97 11:39:21 GMT, David R Tribble
<david.tribble@central.beasys.com> wrote:

>This scheme is reasonably consistent with existing practice, such as the
>following implementations:
>  DEC VAX VMS:      64-bit, 100 nsec ticks since 1601-01-01.

I don't think that's correct. IIRC, the base for VMS time is
Smithsonian Astronomical Observatory Modified Julian Date 0.0 (Julian
Day Number 2400000.5) which fell in November 1858.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>Pete Becker <petebecker@acm.org> writes:
>
>>  Stephen Cipolli wrote:
>>
>> I have heard no defense of the time_t/tm facilities specified in the
Draft,
>> therefore I must assume the draft is flawed in this area and ask that the
>>  standards members consider alternatives.  I am aware this is rather
late,
>>  but ratifying the Draft without fixing the problems is not going to make
>>  them go away.
>
> Nevertheless, last month the standards committee approved the Final
> Draft Information Standard, with unanimous approval of the ANSI
> representatives and of all of the national bodies who attended. So it's
> not just "rather late", but it's far too late. Further, asking "that the
> standards members consider alternatives" won't get anything done. If
> it's important to you, you should have put together a proprosal and done
> the work necessary to get it accepted.
I do not sit on any committee, nor does my position effort me the time or
opportunity to review draft standards or work on any such proposals as you
suggest.  I am a _user_ of the standards work produced by this and other
committees.  And as a user I am attempting to inform the people working on
the C++ language/library that there is a deficiency (IMO) in the way the
draft standard specifies time/calendar.  Just as one might buy a car and
inform the maker of defects in the design.  I do not believe many car makers
respond  to their customers by saying they should have read the design specs
earlier (long before the car was built), and have made alternative proposals
to the design.

As for the idea that this is important only to me and therefore I should
have pursued this earlier.  I can easily build any kind of time/calendar
classes I desire to satisfy my own requirements (as much as I hate to waste
time doing it).  The problem is important to _all_ users, since each will
have to "reinvent the wheel" and will do so in incompatible and perhaps
incorrect ways.  The problem is not personal, it is (or will be) pervasive.

As for "too late".  Things are only too late, if the committee says so and
even then I don't really understand what "too late" means.  Is the committee
going to wait until the draft is completely ratified before considering
proposals for a next version of the standard or does the committee believe
that this is going to be the one and only version?  I think the user
community would be better served by not trying to "put the brakes on"
changes.  Accept or reject whether a problem exists and if it does exist,
start working out the solution.  When or what version of the standard it
gets rolled into is of much less importance.

I'd like to hear simple answers to the question:
Is the current draft's handling of time/calendar adequate for the C++
community?

If the answer is no, then whether it is too late to modify the draft
standard is irrelevant.  The solution needs to be found at some point and
the standard changed; be it version 1 or version 101.

[The previous paragraphs not withstanding, I certainly would be willing to
expend my energies to a time/calendar proposal if a proposal were going to
be considered].
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

ncm@nospam.cantrip.org (Nathan Myers) wrote:

>Such a requirements list would not specify precision or range, just
>the set of operations (in the form of valid expressions) that any
>conforming type would support.  There would be a time_traits<> template
>to describe precision & range, which would be specialized for each
>actual time type.

I described a partial interface of this sort a long time ago on c.s.c++
or c.l.c++.  The trickiest part is defining a calendar-free set of
requirements that would allow the locale to interpret the time classes
using only their traits. If we didn't need to convert between a time
object and its human-readable form, we would have many fewer problems.

>Probably there should be a separate type, for each representation,
>to represent durations, because despite that the two uses are frequently
>conflated they represent different concepts and should be distinguishable
>in the type system.

Agreed. I called this the diff_t trait of the time class.

>A count of time units (seconds, microseconds) since (or until) an epoch
>has nothing to do with any calendar system.  Conversions to and from
>a calendar representation are independent of such choices as range
>and precision.  Certainly, whether to bother with leap seconds is part
>of such a conversion and not of a time representation.

An epoch is irrelevent in the most abstract sense. However, it is
difficult to do without one when defining the interface between a time
class and a general-purpose set of locale facets.  For example, if I
have a time class that represents miliseconds in a narrow range and
another time class that represents hours over a much wider range, I
would like to be able to convert them both to e.g. a western time
representation (human-readable) without having to write the
locale-specific transformations separately for each one.  One way to
accomplish this is to have standard template functions of the form:

 template <class Time>
 string humantime(const locale&, Time);

Implementing such a function requires that we be able to decompose a
Time object in a generic way.  One way to decompose such an object is if
we could get, e.g. the number of seconds since some time origin (epoch).
A reasonable epoch could be, as others have suggested, 1600-01-01 in the
Gregorean calendar. Better yet, each time class could export (via the
traits class) its own epoch, which would in turn be represented as a
Gregorean (or Julian) date. Without this single-point-of-conversion to a
specific calendar, each time class would have to implement its own
human-readable conversion functions based on its own time represention.
Those human-readable conversions would almost certainly be dependent on
a specific calendar and thus would reduce the usefullness of the time
representation for other calendar systems.

>Probably the choice of whether to try to incorporate leap-seconds
>into such a conversion should be left to those who request the
>conversion, rather than second-guessed by a standards group.  An

Agreed. The time traits should probably specify whether leap seconds
are/are not part of the representation by default, but the user should
be able to override that default for specific function calls.
Alternatively adaptors can be added to produce "Time with leap seconds"
or "Time without leap seconds" from some class, Time.

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Disclaimer: Please pardon any misinformation I may give below. I have been
following the standardization of C++ for over two years, but I am not a
member of ANSI or ISO and I repeat their rules from memory. I'm not
intentionally trying to cause trouble, but if I get facts wrong, please
correct me.

Stephen Cipolli wrote in message ...

>As for "too late".  Things are only too late, if the committee says so and
>even then I don't really understand what "too late" means.  Is the
committee
>going to wait until the draft is completely ratified before considering
>proposals for a next version of the standard or does the committee believe
>that this is going to be the one and only version?

This will probably not be the last version, but it will be the last version
for several years. The actual time between revisions is intended to be
approximately five years, but historically language standards bodies have
released revisions closer to once every ten years.

"Too late" means that no proposals can be accepted without delaying the
initial release of the standard by 12 to 24 months. Currently, C++ is a
Final Draft International Standard; by ISO rules, the FDIS will be either
ratified (possibly with minor editorial changes) or not. If not, the
standard returns to national standards bodies (like ANSI) for review and
corrections, a process which takes over a year.

"Too early" means that the C++ committee will not convene again for at least
three years to consider even whether the standard will be revised. They
accept no proposals until after that determination is made.

In the meantime, the committee "merely" answers complaints by issuing Defect
Reports, Technical Corrigenda, and Normative Amendments (in order of
increasing impact and decreasing likelihood). In layman's terms: a Defect
Report states clarifications or acknowledges problems; a Technical
Corrigendum corrects more substantial problems identified in the Defect
Reports, usually in large batches; a Normative Amendment contains major
corrections and additions to the standard. The rough analogues in
constitutional law are bills, statutes, and constitutional amendments.

The addition of a <time> header to expand the limited facilities available
in <ctime> would, I think, be on the order of a Normative Amendment. I don't
know the whole story behind this, but something similar happened in the
standardization of C90. Like C++, the bulk of work on the C standard was
done by ANSI. The other national members of the ISO committee were unhappy
with C's support for internationalization, and some members intended to vote
against the ISO ratification until it was fixed. Rather than delay the
standard by years, they compromised by requiring an amendment to fix
internationalization support. About a year later, they issued NA1, which
added <wctype.h> and <wchar.h> among other things.

>I think the user
>community would be better served by not trying to "put the brakes on"
>changes.  Accept or reject whether a problem exists and if it does exist,
>start working out the solution.  When or what version of the standard it
>gets rolled into is of much less importance.


At this point, the "user committee" needs a language standard more than they
need a great time class. In the meantime, there are still useful steps you
can take. You can lobby your national member body to lobby the ISO committee
to research the time and calandar issues. Then they can choose to issue a
DR, which may lead to a TC (if the existing facilities in <ctime> are
actually broken) or a NA (if they concede that additional facilities are
necessary). An amendment is much more likely if there is a solid proposal
with demonstrated prior art; also lobbying major compiler vendors would help
with establishing "prior art." By the time you're through all the lobbying
and deliberation and red tape, it just might be time to accept new proposals
for the revision in five years.

Keep in mind that by posting complaints here, you're adding one extra level
of indirection to the lobbying process. You're not reaching the committee
here; you're reaching a small minority of (admittedly influential) members,
who may not be especially receptive to a change on the scale of <time>.
You're also not reaching the people who are likely to design and implement
<time> to establish prior art. Finding a "champion" among both the standards
people and the vendors helps a lot.

>I'd like to hear simple answers to the question:
>Is the current draft's handling of time/calendar adequate for the C++
>community?


I must reluctantly answer: yes, it is adequate, although no more than
adequate. The necessary building blocks exist for the most common uses of
time, albeit with a less-than-beautiful interface to the facility. In the
almost ten years since the publication of the C standard, there has not been
enough support for a change to the facility in either language. Apparently
the time and calendar issue is so thorny that the user community feels that
it's a problem best solved by third-party libraries and application-specific
code which address less general needs. Consider the huge list of issues
posted here regarding what's "general enough" for a better solution.

You could argue that the integration of the STL took too much time away from
other parts of the language, but I think that the generic
containers/iterators/algorithms were an excellent if late answer to an
important issue. You could also argue that fixing <ctime> was more important
than adding <complex> and <valarray>, but the committee apparently put a
higher priority on those headers because they had complete proposals that
filled holes in the library, while <ctime> was already adequate with no
compelling proposals to update it.

>If the answer is no, then whether it is too late to modify the draft
>standard is irrelevant.  The solution needs to be found at some point and
>the standard changed; be it version 1 or version 101.


The right path, then, is not to complain that the existing support is weak
(which we know), but to ask what the next steps are for fixing it. That's
information that I don't know myself, but I hope that I've answered at least
some of your questions about why things are the way they are.

If my answers are inaccurate, please correct me so that both Mr. Cipolli and
I know the right answer. I've done my best with the information I have. I'd
also like to know more myself about the amendment process (such as how NA1
came about) and what users can do in the interim between C++98 and C++200x.
---
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Stephen Cipolli wrote:
>
> >Pete Becker <petebecker@acm.org> writes:
> >
> >>  Stephen Cipolli wrote:
> >>
> >> I have heard no defense of the time_t/tm facilities specified in the
> Draft,
> >> therefore I must assume the draft is flawed in this area and ask that the
> >>  standards members consider alternatives.  I am aware this is rather
> late,
> >>  but ratifying the Draft without fixing the problems is not going to make
> >>  them go away.
> >
> > Nevertheless, last month the standards committee approved the Final
> > Draft Information Standard, with unanimous approval of the ANSI
> > representatives and of all of the national bodies who attended. So it's
> > not just "rather late", but it's far too late. Further, asking "that the
> > standards members consider alternatives" won't get anything done. If
> > it's important to you, you should have put together a proprosal and done
> > the work necessary to get it accepted.
> I do not sit on any committee, nor does my position effort me the time or
> opportunity to review draft standards or work on any such proposals as you
> suggest.  I am a _user_ of the standards work produced by this and other
> committees.  And as a user I am attempting to inform the people working on
> the C++ language/library that there is a deficiency (IMO) in the way the
> draft standard specifies time/calendar.  Just as one might buy a car and
> inform the maker of defects in the design.  I do not believe many car makers
> respond  to their customers by saying they should have read the design specs
> earlier (long before the car was built), and have made alternative proposals
> to the design.
>
> As for the idea that this is important only to me and therefore I should
> have pursued this earlier.

I did not suggest that it is important ONLY to you. What I did suggest
is that people who are interested in having particular features in the
language but do not say anything about them until the words of the
standard are in the can are not likely to see their changes made.

>
> As for "too late".  Things are only too late, if the committee says so and
> even then I don't really understand what "too late" means.

It means that the standard is finished, unless someone discovers a major
technical error. Omissions of someone's favorite feature are not major
technical errors.

> Is the committee
> going to wait until the draft is completely ratified before considering
> proposals for a next version of the standard or does the committee believe
> that this is going to be the one and only version?

The standard is fixed for five years by ISO and ANSI rules. In about
five years things will start to gear up for a revision. In the meantime
there is no official body with a charter to consider changes to the C++
standard other than technical corrections and clarifications.

> I think the user
> community would be better served by not trying to "put the brakes on"
> changes.

This standard has been in the works for eight years -- it's definitely
time to "put the brakes on." We actually started doing that four years
ago. The user community is best served by a standard that's actually a
standard -- that is, something that's going to be unchanged for a fairly
long period of time.

> Accept or reject whether a problem exists and if it does exist,
> start working out the solution.  When or what version of the standard it
> gets rolled into is of much less importance.

Take your own advice<g>. You've got five years to put together a
suitable solution to this problem. Specify it, implement it, get
experience with it, repeat until done. Then propose it.

>
> I'd like to hear simple answers to the question:
> Is the current draft's handling of time/calendar adequate for the C++
> community?

A better question is "what facilities for date and time handling would
be most useful in C++"?

 >
 > If the answer is no, then whether it is too late to modify the draft
 > standard is irrelevant.  The solution needs to be found at some point
and
 > the standard changed; be it version 1 or version 101.
 >
 > [The previous paragraphs not withstanding, I certainly would be
willing to
 > expend my energies to a time/calendar proposal if a proposal were
going to
 > be considered].

All the proposals we received were considered. Many were rejected, some
because they lacked technical merit, some because the problems they
solved were not felt to be important enough to solve in a standard, some
because there was a better solution available, some because there was a
somewhat less satisfactory solution available that was much simpler.
However, I don't remember seeing any proposals on dates, times, or
calendars.
 -- Pete
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

B1@acm.org> <m33ejnzns3.fsf@gabi-soft.fr> <ELqHEJ.B6n@news2.new-york.net>

Stephen Cipolli <stephen.cipolli@qed.net> wrote:
>I do not sit on any committee, nor does my position afford me the time or
>opportunity to review draft standards or work on any such proposals as you
>suggest.

Few of us have a position that affords us time to review draft standards.
Nonetheless, some of us do anyhow.  If you wanted to contribute to the
current draft, you would have been welcome.  If you want to contribute
to the next, you will be welcome.

>As for the idea that this is important only to me and therefore I should
>have pursued this earlier...

Nobody thinks this idea is only important to you.  However, importance
must translate into a concrete, viable proposal to be considered for
inclusion in the Standard.

>  Things are only too late, if the committee says so and
>even then I don't really understand what "too late" means.
>...  Accept or reject whether a problem exists and if it does exist,
>start working out the solution.

The committee is composed of volunteers who have plenty to
work on already.  If a problem is important enough to be
worked on, someone (you?) will work on it.  If it is not
being worked on, it is (by definition) not important enough
to consider.  The committee does not issue permission to work
on problems, it only examines the results.

>I'd like to hear simple answers to the question:
>Is the current draft's handling of time/calendar adequate for the C++
>community?

In several peoples' opinion, no.  However, it was adequate to be
accepted unanimously by voting members as a Standard, for now.
At the next release there will certainly be changes; perhaps
including changes in areas of time representation.

>If the answer is no, then whether it is too late to modify the draft
>standard is irrelevant.  The solution needs to be found at some point and
>the standard changed; be it version 1 or version 101.
>
>[The previous paragraphs not withstanding, I certainly would be willing to
>expend my energies to a time/calendar proposal if a proposal were going to
>be considered].

All proposals will be considered when the committee next considers
proposals.  Keep your eyes peeled for announcements.  In the meantime,
if a proposal is written, and implemented, and in wide use when the
committee considers it, there is a much better chance of acceptance.

I am working on a proposal that will appear on my web page, and
be announced here, when it is ready to be looked at.  But don't
wait for me.

Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

"Stephen Cipolli" <stephen.cipolli@qed.net> writes:

|> >Pete Becker <petebecker@acm.org> writes:
|> >
|> >>  Stephen Cipolli wrote:
|> >>
|> >> I have heard no defense of the time_t/tm facilities specified in the
|> Draft,
|> >> therefore I must assume the draft is flawed in this area and ask that the
|> >>  standards members consider alternatives.  I am aware this is rather
|> late,
|> >>  but ratifying the Draft without fixing the problems is not going to make
|> >>  them go away.
|> >
|> > Nevertheless, last month the standards committee approved the Final
|> > Draft Information Standard, with unanimous approval of the ANSI
|> > representatives and of all of the national bodies who attended. So it's
|> > not just "rather late", but it's far too late. Further, asking "that the
|> > standards members consider alternatives" won't get anything done. If
|> > it's important to you, you should have put together a proprosal and done
|> > the work necessary to get it accepted.

|> I do not sit on any committee, nor does my position effort me the time or
|> opportunity to review draft standards or work on any such proposals as you
|> suggest.  I am a _user_ of the standards work produced by this and other
|> committees.  And as a user I am attempting to inform the people working on
|> the C++ language/library that there is a deficiency (IMO) in the way the
|> draft standard specifies time/calendar.  Just as one might buy a car and
|> inform the maker of defects in the design.  I do not believe many car makers
|> respond  to their customers by saying they should have read the design specs
|> earlier (long before the car was built), and have made alternative proposals
|> to the design.

Well, I do contribute to AFNOR, and it does take a lot of time and
effort.  And my contributions are nothing compared to what some others
are doing.

These are all volontary contributions -- in fact, we have to pay to be
able to contribute.  AFNOR receives very little, if any, subsidies from
the French government, and I believe that this is also the case with
ANSI.  (Some of the national bodies are subsidized by their governments
-- this was the case with AFNOR until recently.)  So in a very real
sense, you aren't a paying customer, but a dead beat.  Obviously, if I'm
paying for the privilege of doing the work for you, I'm going to at
least concentrate on the issues that are important to me.  While I agree
globally that a time/calendar class would be a nice addition to the
standard, it's not something important to me, and I'm not willing to
invest any great amount of time and effort to get it.

And the analogy with car makers doesn't hold.  First, because you pay
hard cash for a car -- you don't pay anything for the standard to
exist.  And more importantly, because, as you say, the car makers don't
give you a chance to intervene, before or after.  You take what they
make, or you walk.  In the case of the standard, there is a more or less
democratic process, and you can influence it.  If there had been a
concrete proposal for a time/calendar class, I'm sure the committee
would have considered it.  If it had been good, covering most of the
issues, not breaking anything else in the library, and fitting in with
the rest of the library (particularly iostream), I rather think that it
would have been accepted.

|> As for the idea that this is important only to me and therefore I should
|> have pursued this earlier.  I can easily build any kind of time/calendar
|> classes I desire to satisfy my own requirements (as much as I hate to waste
|> time doing it).  The problem is important to _all_ users, since each will
|> have to "reinvent the wheel" and will do so in incompatible and perhaps
|> incorrect ways.  The problem is not personal, it is (or will be) pervasive.
|>
|> As for "too late".  Things are only too late, if the committee says so and
|> even then I don't really understand what "too late" means.

In this case, "too late" means too late.  The committee doesn't work in
a vacuum; it obeys ISO rules.  And the ISO rules say that, having
presented an FDIS (Final Draft International Standard) for approval, no
changes in the technical content are allowed.

But then, I think that this is all explained in the comp.std.c++ FAQ.
Maybe you don't have the time or the opportunity to read that, either.

|> Is the committee
|> going to wait until the draft is completely ratified before considering
|> proposals for a next version of the standard or does the committee believe
|> that this is going to be the one and only version?

Again, read the FAQ.  The committee is required by ISO procedure to make
no changes at present.  They are also required to consider a new version
no later than five years after the current version has been formally
adopted.

The only real reason to have a standard is stability.  A standard that
changes every 6 months is no better than the current situation, where
every vendor conforms to a different version of the draft.  I need to
write portable code, and for that, I need a stable standard.

|> I think the user
|> community would be better served by not trying to "put the brakes on"
|> changes.  Accept or reject whether a problem exists and if it does exist,
|> start working out the solution.  When or what version of the standard it
|> gets rolled into is of much less importance.
|>
|> I'd like to hear simple answers to the question:
|> Is the current draft's handling of time/calendar adequate for the C++
|> community?
|>
|> If the answer is no, then whether it is too late to modify the draft
|> standard is irrelevant.  The solution needs to be found at some point and
|> the standard changed; be it version 1 or version 101.

Whether you like it or not, it is too late to modify the draft.  Those
are ISO rules, and in this case, there are good reasons for them.

Note that in many ways, having A standard is more important than what is
in the standard.  There are things in the standard which I'm not
completely happy about.  Given the size of the document, and the number
of compromises involved, I would be very surprised if there was any one
who was completely happy about everything in it.  But that's what life
in a democracy is like.

For the moment, the draft is really frozen, and must remain so until it
becomes an official standard.  After that, there are two ways it can
evolve:

1. As mentioned above, five years after adoption, the committee must
consider a revision.  In theory, the result of the consideration can be
a decision that no revision is necessary, but as far as I know, this has
never happened with a language standard yet.  (The C standard -- adopted
in 1989 -- has already undergone a features freeze in its first
revision.)

2. In the case of pure extensions, it is possible to make "normative
addendums" (or something like that) before the revision.  C did
something like this to add some internationalization features, if I'm
not mistaken.

|> [The previous paragraphs not withstanding, I certainly would be willing to
|> expend my energies to a time/calendar proposal if a proposal were going to
|> be considered].

Well, it may be too late for this round, but if you are willing to write
up a concrete proposal, and post it somewhere on the net where it can be
read, people will read it and discuss it.  If they like it, it is
possible that some implementors will adopt it, which increases
noticeably its chances of success in the next round.  (Don't expect
anything to happen too fast on this front, however.  Most implementors
currently have their hands full getting their implementations up to the
level of the draft standard.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

"Bradd W. Szonye" <bradds@concentric.net> writes:

|>  This will probably not be the last version, but it will be the last version
|>  for several years. The actual time between revisions is intended to be
|>  approximately five years, but historically language standards bodies have
|>  released revisions closer to once every ten years.

I think that the situation is simple here.  The requirement is that the
committee start considering a revision five years after the standard has
been adopted.  Since the time necessary between starting to consider a
revision, and the revised version being adopted, is on the order of five
years, we get a ten year interval for the released revisions.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

|>  Christopher Eltschka wrote:
|>  >
|>  > If such a class would be given, it should detect year 0 as error -
|>  > there never was such a year. The year 1 BC is directly followed by 1 AD.
|>  > The reason is that our year numbering was invented before the invention
|>  > of the 0 came to Europe.
|>
|>  Well, it must have come to Europe some time before the year 10.  ;-)
|>
|>  That said, no time class can _really_ handle dates coherently more than a few
|>  centuries back, because the calendar was changed a number of times, and I don't
|>  think scholars have even quite nailed down exactly what changes were made and
|>  when, since 1 A.D. In fact, this is one area in which the Chinese might have a
|>  small advantage over us Westerners in the realm of computer science.

I was about to post the same thing.  I might add that even for the cases
where scholars do have adequate information, the dates would be locale
specific -- the classic Unix cal program, for example, is only accurate
for Great Britain and its ex-colonies.  In Germany, the locale would
have to specify almost down to the village level, as the date the modern
calander was adopted varied from one place to the other.

Of course, talking about future dates is even more risky, since by
definition, we don't know when the next calander reform will take place.
Even without a calander reform, we don't know when the next leap seconds
will occur, so the time function is almost certainly to be wrong even
over the next couple of years.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:

|>  Paul D. DeRocco wrote:
|>  >
|>  > Christopher Eltschka wrote:
|>  > >
|>  > > If such a class would be given, it should detect year 0 as error -
|>  > > there never was such a year. The year 1 BC is directly followed by 1 AD.
|>  > > The reason is that our year numbering was invented before the invention
|>  > > of the 0 came to Europe.
|>  >
|>  > Well, it must have come to Europe some time before the year 10.  ;-)
|>
|>  No, because at that time it was called A.D. X (is this a proof that GUI
|>  programming was known even then? ;-))
|>
|>  BTW, why doesn't C++ support roman numbers like 0rMCMXCVII? :-)

For the same reason it doesn't support binary:-).

|>  > That said, no time class can _really_ handle dates coherently more than a few
|>  > centuries back, because the calendar was changed a number of times, and I don't
|>  > think scholars have even quite nailed down exactly what changes were made and
|>  > when, since 1 A.D. In fact, this is one area in which the Chinese might have a
|>  > small advantage over us Westerners in the realm of computer science.
|>
|>  Well, for a real universal time class, you would have to allow a
|>  configurable calendar (that is, calendar locales which do not deal with
|>  output, but with things like year numbers, months, etc.). Who knows if
|>  the programmer is an Chinese, an Astronomer, or a Star Trek-Fan? (I'm
|>  almost shure, one of the first non-standard date locales would be a
|>  stardate locale ;-)) The way it is represented internally could then
|>  left implementation defined (but a minimum range which is representable
|>  should be specified, of course).

I think that there is software available on the net which can handle
this.  In practice, however, places like Isreal and Saudi Arabia, whose
official date system is not the Gregorian calendar, also use the
Gregorian calendar in parallel.

|>  A possible internal representation could be simply a 64 bit number in
|>  seconds, which would allow a range of about 5.8*10^11 years - I guess
|>  that should be enough for almost every purpose...

I believe that some systems already do so.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

The purpose of my original post was to determine what, if anything, has been
done about the situation (namely facilities for representing and
manipulating time/calendar
info.) and to perhaps start a dialog on whether or not such facilities in
the current draft are broken or inadequate.  We seem to be putting the cart
before the horse.  The responses have, for the most part, been focusing on
the details (which is great), but if there is no broad concensus that any
change will be made to the draft before it is published, the effort is for
naught.

My opinion is the standard should not be published without some sort of
time/calendar class which integrates with the rest of the standard C++
library.  Time/calendar concept is simply too fundamental to be ignored,
particularly when such alternatives as the standard C library facilities are
so inadequate (here I am referring to the version of the standard C library
without the latest changes... Having no real info. on the current changes
and so reserve my opinion for the moment).

I have heard no defense of the time_t/tm facilities specified in the Draft,
therefore I must assume the draft is flawed in this area and ask that the
standards members consider alternatives.  I am aware this is rather late,
but ratifying the Draft without fixing the problems is not going to make
them go away.  Instead they'll linger on and on and cause compatibility
issues in the future.

BTW, just for the record:
    1. Yes, I understand 0 A.D. did not exist (I apologize for the slip).

    2. There have been a great number of calendars, each used at different
times and in different locales.

    3. Presently, the vast majority of the world uses the Gregorian calendar
and it is the most accurate (not counting astronomers/scientific calendars).

    4. Regardless of when it was invented or used by a particular locale,
the Gregorian calendar can represent time as far back in the past and as far
into the future as needed.

    5. Translation to and from other calendars (particularly the Julian
calendar) is an interesting specialty best left for specialty libraries.

    6. Translation of particular dates to/from other calendars is a task
best left to historians and theologians.

    7. Any library built for time/calendar purposes can and IMO should not
use global memory.  Time zone can be applied as a filter to a time
represenation at the point of output.  The actual value of such a timezone
filter most likely must be set "by hand" (since it is unlikely that many
computers have Global Positioning System [GPS] hardware and software to
translate a position into a timezone.).  However the number of timezone
filters available to a program at any one time should not be constrained (as
it is in the current standard C library).

8. IMO, any time/calendar facility must minimally provide addition,
subtraction and relational operations.

9. IMO, any time/calendar facility must be capable of representing nearly
any year
(a 32-bit quantity can represent nearly 4.3 billion years).

Angelika Langer wrote in message <34914F4A.EE168BBC@camelot.de>...
>Matt Austern wrote:
>>
>> Angelika Langer <langer@camelot.de> writes:
>>
>> > Not quite true for C++. C++ locales are thread-safe, at least there is
>> > nothing that would stop library vendors from making them thread-safe.
>> > Locale objects are instances of a class that does not depend on global
>> > or static variables. Facets, the "parts" of a C++ locale, are passed
>> > around by reference, but are guaranteed to be immutable. And so on and
>> > so forth. C++ locales are perfectly thread-safe in the sense you
>> > indicated above.
>>
>> Except that facets do depend on global data.  (The static member
>> variable id.)  You do have to worry about synchronization if you're
>> implementing locales.
>
>Yes, if you're implementing them, then you have to care, and you CAN
>care. The static id member is the only crucial piece in locale. Very
>different from the global locale in C that simply cannot be made
>thread-safe. A user of a C locale will always have to care about race
>conditions in access to the global locale. Pretty much like a user of
>the STL will be confronted with synchronization issues as soon as (s)he
>share iterators among threads. That's something that you as someone
>implementing the STL cannot solve for him/her.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Stephen Cipolli wrote:
>
> I have heard no defense of the time_t/tm facilities specified in the Draft,
> therefore I must assume the draft is flawed in this area and ask that the
> standards members consider alternatives.  I am aware this is rather late,
> but ratifying the Draft without fixing the problems is not going to make
> them go away.

Nevertheless, last month the standards committee approved the Final
Draft Information Standard, with unanimous approval of the ANSI
representatives and of all of the national bodies who attended. So it's
not just "rather late", but it's far too late. Further, asking "that the
standards members consider alternatives" won't get anything done. If
it's important to you, you should have put together a proprosal and done
the work necessary to get it accepted.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

On 16 Dec 1997 17:16:46 PST, "Stephen Cipolli"
<stephen.cipolli@qed.net> wrote:

>The purpose of my original post was to determine what, if anything, has been
>done about the situation (namely facilities for representing and
>manipulating time/calendar
>info.) and to perhaps start a dialog on whether or not such facilities in
>the current draft are broken or inadequate.  ...

This newsgroup exists for the purpose of such dialog. I don't know of
anyone who thinks that what we have is sufficient, so maybe we could
just start with your list of desiderata.

>My opinion is the standard should not be published without some sort of
>time/calendar class which integrates with the rest of the standard C++
>library.

Perhaps so, but it is now too late. It would have been better to make
such observations, along with a concrete proposal, during the first
public-comment period in 1995. Requests for extensions since then have
been rejected on the grounds of not enough time to deal with them.
Requests for extensions without a concrete proposal are somewhat
pointless. *Someone* must work up a complete proposal, and committee
members (who are all unpaid volunteers) normally have plenty to do
already.

The standard comes up for review five years after publication. Perhaps
by that time someone will have created a set of time and date classes
that could be added to the standard.

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <EL9n31.CK2@news2.new-york.net>,
Stephen Cipolli <stephen.cipolli@qed.net> wrote:
>The purpose of my original post was to determine what, if anything, has been
>done about the situation (namely facilities for representing and
>manipulating time/calendar...
>
>My opinion is the standard should not be published without some sort of
>time/calendar class which integrates with the rest of the standard C++
>library. ...

In other words, we should delay the standard while we wait for
a suitable time/date apparatus to be invented, refined, and
codified?  In my opinion, and the opinion of all the committee
members who attended the November '97 meeting, the immediate need
for a standard is greater than the need for a solution in this area.

This is not to say that nobody should work on a solution.

>I have heard no defense of the time_t/tm facilities specified in the Draft,
>therefore I must assume the draft is flawed in this area and ask that the
>standards members consider alternatives.

The current facilities are not broken, but are clearly not ultimately
sufficient either.  In particular, time_t is sufficient to represent
"now" and short periods before and after; conversion to a user type
of greater range is a reasonable way to extend the capabilities.
Similarly, struct tm is cumbersome but entirely sufficient for
communicating between libraries about dates and times far into the
past and future.  What is lacking, particularly, is re-entrant time
zone support.

However, no proposal was presented during the time when one could have
been considered.

>   I am aware this is rather late,
>but ratifying the Draft without fixing the problems is not going to make
>them go away.  Instead they'll linger on and on and cause compatibility
>issues in the future.

The problems will certainly be addressed in the future.

>    7. Any library built for time/calendar purposes can and IMO should not
>use global memory.  Time zone can be applied as a filter to a time
>represenation at the point of output.  The actual value of such a timezone
>filter most likely must be set "by hand" (since it is unlikely that many
>computers have Global Positioning System [GPS] hardware and software to
>translate a position into a timezone.).  However the number of timezone
>filters available to a program at any one time should not be constrained (as
>it is in the current standard C library).

The most natural way to present such an interface is as a locale facet.

>8. IMO, any time/calendar facility must minimally provide addition,
>subtraction and relational operations.
>
>9. IMO, any time/calendar facility must be capable of representing nearly
>any year
>(a 32-bit quantity can represent nearly 4.3 billion years).

There are many possible "compact" representations for time and date
that represent different tradeoffs.  It may be that a future standard
should describe requirements for template parameters intended to
represent such types, rather than defining a particular type.

Nathan Myers
ncm@nospam.cantrip.org
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Christopher Eltschka wrote:
...
> A possible internal representation could be simply a 64 bit number in
> seconds, which would allow a range of about 5.8*10^11 years - I guess
> that should be enough for almost every purpose...

The problem with such a representation is that the precision of the
resulting number would vary drastically over the range of dates to be
covered, and might be insufficient for some applications for large time
values.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Pete Becker <petebecker@acm.org> wrote:
>Stephen Cipolli wrote:
>> I have heard no defense of the time_t/tm facilities specified in the Draft,

<double take>  You mean the facilities inherited from C?

>> therefore I must assume the draft is flawed in this area and ask that the
>> standards members consider alternatives.  I am aware this is rather late,
>> but ratifying the Draft without fixing the problems is not going to make
>> them go away.
>
>Nevertheless, last month the standards committee approved the Final
>Draft Information Standard, with unanimous approval of the ANSI
>representatives and of all of the national bodies who attended. So it's
>not just "rather late", but it's far too late.

Not at all... it's "too early" for the next round that starts in five
years (or more). :-)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Russell Kuyper Jr. wrote:
>
> Christopher Eltschka wrote:
> ...
> > A possible internal representation could be simply a 64 bit number in
> > seconds, which would allow a range of about 5.8*10^11 years - I guess
> > that should be enough for almost every purpose...
>
> The problem with such a representation is that the precision of the
> resulting number would vary drastically over the range of dates to be
> covered, and might be insufficient for some applications for large time
> values.

Besides the fact that I wrote "*almost* every purpose", I don't see this
varying precision. Indeed, with my suggestion, the precision is always
the
same: 1 second. The only types I know which have varying (absolute)
precision are floating point types. But if I had had floating point
numbers
in mind, I'd have said so (OTOH, I can imagine applications where
floating points would be the better choice - then with a typical
64 bit double, you could get a range up to 10^308 years at cost of
exactness, or fractions of seconds if you restrict yourself at a smaller
range)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Pete Becker <petebecker@acm.org> writes:

|>  Stephen Cipolli wrote:
|>  >
|>  > I have heard no defense of the time_t/tm facilities specified in the Draft,
|>  > therefore I must assume the draft is flawed in this area and ask that the
|>  > standards members consider alternatives.  I am aware this is rather late,
|>  > but ratifying the Draft without fixing the problems is not going to make
|>  > them go away.
|>
|>  Nevertheless, last month the standards committee approved the Final
|>  Draft Information Standard, with unanimous approval of the ANSI
|>  representatives and of all of the national bodies who attended. So it's
|>  not just "rather late", but it's far too late. Further, asking "that the
|>  standards members consider alternatives" won't get anything done. If
|>  it's important to you, you should have put together a proprosal and done
|>  the work necessary to get it accepted.

To which I might add that the C standards committee has just issued a
CD, and as far as I know, there are no modifications to the time
handling (except maybe correcting a few small errors, such as allowing
tm_sec to have a maximum of 61 instead of 60).  While no one (that I
know) seems to be fully satisfied with the existing status, no one seems
to consider it important enough to have come up with a concrete proposal
for improvement.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

ncm@best.com (Nathan Myers) wrote:
>
> Stephen Cipolli <stephen.cipolli@qed.net> wrote:
> >The purpose of my original post was to determine what, if anything, has been
> >done about the situation (namely facilities for representing and
> >manipulating time/calendar...
> >
> >My opinion is the standard should not be published without some sort of
> >time/calendar class which integrates with the rest of the standard C++
> >library. ...

> >I have heard no defense of the time_t/tm facilities specified in the Draft,
> >therefore I must assume the draft is flawed in this area and ask that the
> >standards members consider alternatives.
>
> The current facilities are not broken, but are clearly not ultimately
> sufficient either.  In particular, time_t is sufficient to represent
> "now" and short periods before and after; conversion to a user type
> of greater range is a reasonable way to extend the capabilities.
> Similarly, struct tm is cumbersome but entirely sufficient for
> communicating between libraries about dates and times far into the
> past and future.  What is lacking, particularly, is re-entrant time
> zone support.
>
> However, no proposal was presented during the time when one could have
> been considered.

> >8. IMO, any time/calendar facility must minimally provide addition,
> >subtraction and relational operations.
> >
> >9. IMO, any time/calendar facility must be capable of representing nearly
> >any year
> >(a 32-bit quantity can represent nearly 4.3 billion years).
>
> There are many possible "compact" representations for time and date
> that represent different tradeoffs.  It may be that a future standard
> should describe requirements for template parameters intended to
> represent such types, rather than defining a particular type.

A good starting point would probably be a 64-bit binary (long long int)
time type that represents the number of ticks since 1601-01-01 00:00:00 UTC,
where each tick is one microsecond.  This gives a usable range of 292,270
years using positive values, while providing subsecond precision.  The
Gregorian calendar should be employed (even though some countries used
different calendars before its adoption).  Using a single calendar encoding
gives a consistent and standard reckoning scheme.

Negative years would be allowed, capable of representing dates prior to
1601.  B.C. dates would be handled as well; 1 B.C. would be year number 0,
2 B.C. is year -1, etc.  This is consistent with current ISO-8601 encoding,
and also with the Julian day numbering system used by astronomers.

Even though the encoding has subsecond precision, leap seconds should not
be encoded, because it complicates the encoding.  But leap seconds should
be allowed to appear in expanded encodings (so that 23:59:60 is a valid
time).  This is consistent with POSIX 'time_t', and ISO C 'struct tm' and
'struct tmx' encodings.

This scheme is reasonably consistent with existing practice, such as the
following implementations:
  DEC VAX VMS:      64-bit, 100 nsec ticks since 1601-01-01.
  Microsoft Win32:  64-bit, 100 nsec ticks since 1601-01-01.
  ANSI COBOL:       Time & date functions, days since 1601-01-01.

Other systems use different epochs, but can be converted without too
much difficulty.  For example:
  POSIX:            32-bit, secs since 1970-01-01, with 32-bit usec.
  IBM CICS:         15-digit packed decimal, 1 msec ticks since 1900-01-01.
  etc.

The new time type could be defined as a simple typedef, say, 'ltime_t'
(a.k.a., "long time type").  One or more classes could then be build on
top of this type, providing a sufficiently ample set of conversion,
arithmetic, and comparison functions and operators to manipulate time
values.  Of course, there would also be functions to convert back and
forth from the existing 'time_t', 'struct tm', and 'struct tmx' types
as well.  And strftime() formatting would also be supported.

And of course, all of the functions would be thread-safe, i.e., they
would not rely on any non-const global data between calls.

Other classes could then be built to provide conversions to other calendar
systems and other locale-specific conventions (though these would probably
not be standardized.)

-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Matt Austern wrote:
>
> Angelika Langer <langer@camelot.de> writes:
>
> > Not quite true for C++. C++ locales are thread-safe, at least there is
> > nothing that would stop library vendors from making them thread-safe.
> > Locale objects are instances of a class that does not depend on global
> > or static variables. Facets, the "parts" of a C++ locale, are passed
> > around by reference, but are guaranteed to be immutable. And so on and
> > so forth. C++ locales are perfectly thread-safe in the sense you
> > indicated above.
>
> Except that facets do depend on global data.  (The static member
> variable id.)  You do have to worry about synchronization if you're
> implementing locales.

Yes, if you're implementing them, then you have to care, and you CAN
care. The static id member is the only crucial piece in locale. Very
different from the global locale in C that simply cannot be made
thread-safe. A user of a C locale will always have to care about race
conditions in access to the global locale. Pretty much like a user of
the STL will be confronted with synchronization issues as soon as (s)he
share iterators among threads. That's something that you as someone
implementing the STL cannot solve for him/her.


--
--------------------------------------------------------------------------
Angelika Langer
Training & Consulting
Object-Oriented Software Development in C++ &
Java
Neumarkter Str. 86d, D-81673 Munich, Germany
Phone: +49-89-436 38 54
Email: langer@camelot.de
http://www.camelot.de/~langer/
--------------------------------------------------------------------------
Keep your face to the sunshine and you will not see the shadows.
(Native Indian wisdom)
--------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David R Tribble  <david.tribble@central.beasys.com> wrote:
> <austern@isolde.mti.sgi.com> wrote:
>> Angelika Langer <langer@camelot.de> writes:
>>
>> > C++ locales are thread-safe, at least there is
>> > nothing that would stop library vendors from making them thread-safe.
>>
>> Except that facets do depend on global data.  (The static member
>> variable id.)  You do have to worry about synchronization if you're
>> implementing locales.

Still, nothing in the interface prevents making them thread-safe,
unlike the C library functions David complains of.

>I was also referring to ALL of the library functions that are not thread-
>safe, not just the locale functions.  The following functions rely on
>global data:
> [list omitted]
>These functions rely on global data between calls, and thus require
>special efforts to be made thread-safe.  I suggested that for each of
>these functions, a new function be invented (or be borrowed from POSIX)
>that takes an extra pointer argument, in order to make its thread-safe
>implementation easier.

The C++ committee was obliged to be compatible with the C library,
not to fix it.  Instead, the C++ library implements facilities with
a C++ interface to replace C library functions.  A few of the C library
functions are not covered, particularly the localtime() family, mainly
because we got no proposals.  That is unfortunate, and will (I hope) be
remedied at the next round, in five years, as a locale facet.

I see no point in tinkering with the C interfaces.  The greatest
merit of C is (was?) its stability.

Nathan Myers
ncm@nospam.cantrip.org
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Christopher Eltschka wrote:
>
> If such a class would be given, it should detect year 0 as error -
> there never was such a year. The year 1 BC is directly followed by 1 AD.
> The reason is that our year numbering was invented before the invention
> of the 0 came to Europe.

Well, it must have come to Europe some time before the year 10.  ;-)

That said, no time class can _really_ handle dates coherently more than a few
centuries back, because the calendar was changed a number of times, and I don't
think scholars have even quite nailed down exactly what changes were made and
when, since 1 A.D. In fact, this is one area in which the Chinese might have a
small advantage over us Westerners in the realm of computer science.

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

David R Tribble wrote:

> While all of this applies to C, the C++ committee is tracking the C
> standard, presumably with the intent of incorporating the C library into
> the C++ library (?).

The ISO/ANSI C library is part of the ISO/ANSI C++ library, as far as I
know.

> Unfortunately, neither the ISO C or C++ committee seem very interested in
> adopting reentrant-safe or thread-safe library functions.  (I made a
> proposal to both committees for a 'thread-safe library', but too late to
> be considered.)  It's a simple matter of providing functions that do not
> rely on, nor return pointers to, global variables; the new functions would
> simply take extra pointer arguments.  POSIX already has alternate versions
> of the unsafe library functions (e.g., localtime_r()), but the ISO committees
> are reticent, for some reason, to adopt these now.

Not quite true for C++. C++ locales are thread-safe, at least there is
nothing that would stop library vendors from making them thread-safe.
Locale objects are instances of a class that does not depend on global
or static variables. Facets, the "parts" of a C++ locale, are passed
around by reference, but are guaranteed to be immutable. And so on and
so forth. C++ locales are perfectly thread-safe in the sense you
indicated above.

--
--------------------------------------------------------------------------
Angelika Langer
Training & Consulting
Object-Oriented Software Development in C++ &
Java
Neumarkter Str. 86d, D-81673 Munich, Germany
Phone: +49-89-436 38 54
Email: langer@camelot.de
http://www.camelot.de/~langer/
--------------------------------------------------------------------------
Keep your face to the sunshine and you will not see the shadows.
(Native Indian wisdom)
--------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Angelika Langer <langer@camelot.de> writes:

> Not quite true for C++. C++ locales are thread-safe, at least there is
> nothing that would stop library vendors from making them thread-safe.
> Locale objects are instances of a class that does not depend on global
> or static variables. Facets, the "parts" of a C++ locale, are passed
> around by reference, but are guaranteed to be immutable. And so on and
> so forth. C++ locales are perfectly thread-safe in the sense you
> indicated above.

Except that facets do depend on global data.  (The static member
variable id.)  You do have to worry about synchronization if you're
implementing locales.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

> Stephen Cipolli wrote:
>
> [...]
>
> > By providing a class (lets call it "rt_clock") to return the current time as
> > an object of class time (or some other suitable name), providing arithmetic
> > for the class time, and allowing let's say all dates from 0 AD, then C++
> > code would be impervious to the transition from 32 bit time_t to 64 bit
> > time_t.  Of course conversions to tm and time_t would need to be provided
> > for backward compatibility.

Most people who have any use for dates earlier than 1000 AD, probably
need to handle dates earlier than 1 AD, so I don't think that would be a
good solution (even ignoring the fact that 0 AD is a non-existent year).

A better solution would be to store some version of the Julian Date that
has already been used for quite a while by both astronomers and
historians:
 <http://www.faqs.org/faqs/astronomy/faq/part3/section-7.html>
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Paul D. DeRocco wrote:
>
> Christopher Eltschka wrote:
> >
> > If such a class would be given, it should detect year 0 as error -
> > there never was such a year. The year 1 BC is directly followed by 1 AD.
> > The reason is that our year numbering was invented before the invention
> > of the 0 came to Europe.
>
> Well, it must have come to Europe some time before the year 10.  ;-)

No, because at that time it was called A.D. X (is this a proof that GUI
programming was known even then? ;-))

BTW, why doesn't C++ support roman numbers like 0rMCMXCVII? :-)

>
> That said, no time class can _really_ handle dates coherently more than a few
> centuries back, because the calendar was changed a number of times, and I don't
> think scholars have even quite nailed down exactly what changes were made and
> when, since 1 A.D. In fact, this is one area in which the Chinese might have a
> small advantage over us Westerners in the realm of computer science.

Well, for a real universal time class, you would have to allow a
configurable calendar (that is, calendar locales which do not deal with
output, but with things like year numbers, months, etc.). Who knows if
the programmer is an Chinese, an Astronomer, or a Star Trek-Fan? (I'm
almost shure, one of the first non-standard date locales would be a
stardate locale ;-)) The way it is represented internally could then
left implementation defined (but a minimum range which is representable
should be specified, of course).

A possible internal representation could be simply a 64 bit number in
seconds, which would allow a range of about 5.8*10^11 years - I guess
that should be enough for almost every purpose...
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

In <fxtk9dfkabz.fsf@isolde.mti.sgi.com>, Matt Austern
 <austern@isolde.mti.sgi.com> wrote:
> Angelika Langer <langer@camelot.de> writes:
>
> > Not quite true for C++. C++ locales are thread-safe, at least there is
> > nothing that would stop library vendors from making them thread-safe.
> > Locale objects are instances of a class that does not depend on global
> > or static variables. Facets, the "parts" of a C++ locale, are passed
> > around by reference, but are guaranteed to be immutable. And so on and
> > so forth. C++ locales are perfectly thread-safe in the sense you
> > indicated above.
>
> Except that facets do depend on global data.  (The static member
> variable id.)  You do have to worry about synchronization if you're
> implementing locales.

I was also referring to ALL of the library functions that are not thread-
safe, not just the locale functions.  The following functions rely on
global data:

     asctime()          <time.h>        7.12.3.1
     ctime()            <time.h>        7.12.3.2
     gmtime()           <time.h>        7.12.3.3
     localtime()        <time.h>        7.12.3.4
     rand()             <stdlib.h>      7.10.2.1
     setlocale()        <locale.h>      7.4.1.1
     strerror()         <string.h>      7.11.6.2
     strtok()           <string.h>      7.11.5.8
     wcstok()           <string.h>      7.11.?.?

(Section numbers are from the ISO C89 standard.)
These functions rely on global data between calls, and thus require
special efforts to be made thread-safe.  I suggested that for each of
these functions, a new function be invented (or be borrowed from POSIX)
that takes an extra pointer argument, in order to make its thread-safe
implementation easier.

See my proposal for thread-safe functions at:
  <http://www.flash.net/~dtribble/text/c9xthr.txt>
I think I covered all the thread-unsafe functions in C89, but I'm sure
there are new ones in C9X that I didn't know about.

-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Angelika Langer <langer@camelot.de> writes:

:David R Tribble wrote:
:
:> Unfortunately, neither the ISO C or C++ committee seem very interested in
:> adopting reentrant-safe or thread-safe library functions.  (I made a
:> proposal to both committees for a 'thread-safe library', but too late to
:> be considered.)  It's a simple matter of providing functions that do not
:> rely on, nor return pointers to, global variables; the new functions would
:> simply take extra pointer arguments.  POSIX already has alternate versions
:> of the unsafe library functions (e.g., localtime_r()), but the ISO committees
:> are reticent, for some reason, to adopt these now.
:
:Not quite true for C++. C++ locales are thread-safe, at least there is
:nothing that would stop library vendors from making them thread-safe.

there is nothing in the C++ standard that prevents a thread-safe library
implementation that i'm aware of.  for example, on the implementation i use
most often, strtok() is perfectly thread safe --- no reason to deal with
"strtok_r" or some suchh nonsense (granted, there's rarely much use for
strtok as well..)

 --xmsb
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

I've recently had the need for time and date capabilities and was
surprised to find in the December 1996 Draft that there were no new C++
classes in support of time and date beyond the C Standard library (with
the excpetion of <locale> related facets).

I've been away from this mailing list for sometime, so I apologize in
advance if this topic has come and gone.  Has there been a time class
introduced?

The C standard library functions IMHO are rather weak in many respects,
given the power of C++ and state of technology.

C++ provides powerful mechanisms for encapsulating information like time,
it would be a shame to force users to use tm/time_t.  The tm/time_t types
have several problems (IMO):
1. tm provides no validation of individual fields (day = 67).

2. tm provides no validation between fields (Fri Nov 29, 1997 [day of week
is wrong]).

3. time_t only typically handles time (on 32-bit CPU's) from Jan 1, 1970 to
Feb. ?,  2036. Considering the hoopla going on over the year 2000 problem,
I'm sure there will eventually be a need for a transition to something
better (64-bit time_t's).  Now seems the right time for C++ to protect users
from such a transition.

4. Programs dealing in historical information are left out in the cold for
time arithmetic.
time_t is typically limited in range (as stated above) because a computer
has no need to return a value representing something like "July 17, 1907
02:11:00" as the current time.  Therefore, time_t  is limited in range but
arithmetic is only specified for time_t objects (via difftime).  So even
though a tm object can hold historical dates, they can not be compared with
the C library.

5. The manipulation functions for tm/time_t consider only UTC and the local
time zones.
To display times in various timezones together, global variables need to be
set and reset and/or environment variables changed. This is cumbersome and
error prone. [Note: This problem is mitigated by the <locale> facet, but use
of it seems to allow only a single output format per locale].

6. The several manipulation routines (gmtime, localtime, and mktime) depend
upon a single global tm structure.  While this scheme made sense in the days
of single threaded processes, it makes little sense today. Yes, thread local
storage makes this a non-issue on most OS's (sometimes at the cost of
efficiency), but modern libraries should not depend on such mechanisms
(IMO).

By providing a class (lets call it "rt_clock") to return the current time as
an object of class time (or some other suitable name), providing arithmetic
for the class time, and allowing let's say all dates from 0 AD, then C++
code would be impervious to the transition from 32 bit time_t to 64 bit
time_t.  Of course conversions to tm and time_t would need to be provided
for backward compatibility.

IMO, not providing a time class, is akin to not providing a string class.
Neither is absolutely necessary (after we could live with char* if we
didn't have a string class), but if no standard is set out, then each
vendor will create their own, each with incompatible interfaces.

--Stephen Cipolli

P.S. I'm really hoping that I either do not understand something important
about the existing <ctime> or that some progress in this area has already
been made.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

What would the class's interface look like?

For example, I don't think that Java's GregorianCalender class would be
a particularly friendly interface to emulate.

Stephen Cipolli wrote:
>
> I've recently had the need for time and date capabilities and was
> surprised to find in the December 1996 Draft that there were no new C++
> classes in support of time and date beyond the C Standard library (with
> the excpetion of <locale> related facets).
>
> I've been away from this mailing list for sometime, so I apologize in
> advance if this topic has come and gone.  Has there been a time class
> introduced?
>
> The C standard library functions IMHO are rather weak in many respects,
> given the power of C++ and state of technology.
>
> C++ provides powerful mechanisms for encapsulating information like time,
> it would be a shame to force users to use tm/time_t.  The tm/time_t types
> have several problems (IMO):
> 1. tm provides no validation of individual fields (day = 67).
>
> 2. tm provides no validation between fields (Fri Nov 29, 1997 [day of week
> is wrong]).
>
> 3. time_t only typically handles time (on 32-bit CPU's) from Jan 1, 1970 to
> Feb. ?,  2036. Considering the hoopla going on over the year 2000 problem,
> I'm sure there will eventually be a need for a transition to something
> better (64-bit time_t's).  Now seems the right time for C++ to protect users
> from such a transition.
>
> 4. Programs dealing in historical information are left out in the cold for
> time arithmetic.
> time_t is typically limited in range (as stated above) because a computer
> has no need to return a value representing something like "July 17, 1907
> 02:11:00" as the current time.  Therefore, time_t  is limited in range but
> arithmetic is only specified for time_t objects (via difftime).  So even
> though a tm object can hold historical dates, they can not be compared with
> the C library.
>
> 5. The manipulation functions for tm/time_t consider only UTC and the local
> time zones.
> To display times in various timezones together, global variables need to be
> set and reset and/or environment variables changed. This is cumbersome and
> error prone. [Note: This problem is mitigated by the <locale> facet, but use
> of it seems to allow only a single output format per locale].
>
> 6. The several manipulation routines (gmtime, localtime, and mktime) depend
> upon a single global tm structure.  While this scheme made sense in the days
> of single threaded processes, it makes little sense today. Yes, thread local
> storage makes this a non-issue on most OS's (sometimes at the cost of
> efficiency), but modern libraries should not depend on such mechanisms
> (IMO).
>
> By providing a class (lets call it "rt_clock") to return the current time as
> an object of class time (or some other suitable name), providing arithmetic
> for the class time, and allowing let's say all dates from 0 AD, then C++
> code would be impervious to the transition from 32 bit time_t to 64 bit
> time_t.  Of course conversions to tm and time_t would need to be provided
> for backward compatibility.
>
> IMO, not providing a time class, is akin to not providing a string class.
> Neither is absolutely necessary (after we could live with char* if we
> didn't have a string class), but if no standard is set out, then each
> vendor will create their own, each with incompatible interfaces.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Stephen Cipolli wrote:
>
> I've recently had the need for time and date capabilities and was
> surprised to find in the December 1996 Draft that there were no new C++
> classes in support of time and date beyond the C Standard library (with
> the excpetion of <locale> related facets).
>
> I've been away from this mailing list for sometime, so I apologize in
> advance if this topic has come and gone.  Has there been a time class
> introduced?
>
> The C standard library functions IMHO are rather weak in many respects,
> given the power of C++ and state of technology.
>
> C++ provides powerful mechanisms for encapsulating information like time,
> it would be a shame to force users to use tm/time_t.  The tm/time_t types
> have several problems (IMO):
>
> 1. tm provides no validation of individual fields (day = 67).
>
> 2. tm provides no validation between fields (Fri Nov 29, 1997 [day of week
> is wrong]).
>
> 3. time_t only typically handles time (on 32-bit CPU's) from Jan 1, 1970 to
> Feb. ?,  2036. Considering the hoopla going on over the year 2000 problem,
> I'm sure there will eventually be a need for a transition to something
> better (64-bit time_t's).  Now seems the right time for C++ to protect users
> from such a transition.
>
> 4. Programs dealing in historical information are left out in the cold for
> time arithmetic.
> time_t is typically limited in range (as stated above) because a computer
> has no need to return a value representing something like "July 17, 1907
> 02:11:00" as the current time.  Therefore, time_t  is limited in range but
> arithmetic is only specified for time_t objects (via difftime).  So even
> though a tm object can hold historical dates, they can not be compared with
> the C library.
>
> 5. The manipulation functions for tm/time_t consider only UTC and the local
> time zones.
> To display times in various timezones together, global variables need to be
> set and reset and/or environment variables changed. This is cumbersome and
> error prone. [Note: This problem is mitigated by the <locale> facet, but use
> of it seems to allow only a single output format per locale].
>
> 6. The several manipulation routines (gmtime, localtime, and mktime) depend
> upon a single global tm structure.  While this scheme made sense in the days
> of single threaded processes, it makes little sense today. Yes, thread local
> storage makes this a non-issue on most OS's (sometimes at the cost of
> efficiency), but modern libraries should not depend on such mechanisms
> (IMO).
>
> By providing a class (lets call it "rt_clock") to return the current time as
> an object of class time (or some other suitable name), providing arithmetic
> for the class time, and allowing let's say all dates from 0 AD, then C++
> code would be impervious to the transition from 32 bit time_t to 64 bit
> time_t.  Of course conversions to tm and time_t would need to be provided
> for backward compatibility.
>
> IMO, not providing a time class, is akin to not providing a string class.
> Neither is absolutely necessary (after we could live with char* if we
> didn't have a string class), but if no standard is set out, then each
> vendor will create their own, each with incompatible interfaces.

All of these are valid points.

The recently approved draft of the ISO C standard (C9X) added a new
'struct tmx' extended time type, described in section 7.16.  The new
structure contains extra fields for more exact timezone handling, and a
version number field for future additions.  In addition, they've added the
following functions that operate on or return tmx structure objects:
    mkxtime()
    strfxtime()
    timezone()

Also, they've extended the range of tmx.tm_year to cover negative year
numbers (i.e., years prior to 1900), allowing any valid date using the
Gregorian calendar encoding, including years prior to A.D. 1.

mktime() has always normalized the values of the tm struct, and mkxtime()
does the same for its tmx argument.

While all of this applies to C, the C++ committee is tracking the C
standard, presumably with the intent of incorporating the C library into
the C++ library (?).

Unfortunately, neither the ISO C or C++ committee seem very interested in
adopting reentrant-safe or thread-safe library functions.  (I made a
proposal to both committees for a 'thread-safe library', but too late to
be considered.)  It's a simple matter of providing functions that do not
rely on, nor return pointers to, global variables; the new functions would
simply take extra pointer arguments.  POSIX already has alternate versions
of the unsafe library functions (e.g., localtime_r()), but the ISO committees
are reticent, for some reason, to adopt these now.

Maybe next time (no pun intended).

-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

On 03 Dec 97 15:29:41 GMT, David R Tribble
<david.tribble@central.beasys.com> wrote:

>The recently approved draft of the ISO C standard (C9X) added a new
>'struct tmx' extended time type, described in section 7.16.  ...
>
>While all of this applies to C, the C++ committee is tracking the C
>standard, presumably with the intent of incorporating the C library into
>the C++ library (?).

The final draft of the C++ standard was approved in November and is
going out for balloting by ISO member nations. Since the new C
standard is not complete, it isn't possible for the C++ standard to
track it. In fact, we had to stop adding new features, other than
minor tweaks, more than a year ago.

I would expect something like this to happen: As vendors move to the
new C standard, they will make the new C features available in their
C++ implementations. When the C++ standard comes up for review, it
will be a simple matter of validating the new C features as part of
C++. (One wouldn't expect it to be simple a priori, but the C
committee has tried to ensure that the new features do not prevent C++
compatibility.)

>Unfortunately, neither the ISO C or C++ committee seem very interested in
>adopting reentrant-safe or thread-safe library functions.  (I made a
>proposal to both committees for a 'thread-safe library', but too late to
>be considered.)

The C++ committee did not want to tackle that issue, given all that we
had to do already. We did require implementations to document which
library functions are thread-safe. As it happens, some implementations
(like the one from Sun Microsystems) are thread-safe anyway.

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Stephen Cipolli wrote:

[...]

> By providing a class (lets call it "rt_clock") to return the current time as
> an object of class time (or some other suitable name), providing arithmetic
> for the class time, and allowing let's say all dates from 0 AD, then C++
> code would be impervious to the transition from 32 bit time_t to 64 bit
> time_t.  Of course conversions to tm and time_t would need to be provided
> for backward compatibility.

If such a class would be given, it should detect year 0 as error -
there never was such a year. The year 1 BC is directly followed by 1 AD.
The reason is that our year numbering was invented before the invention
of the 0 came to Europe.

[...]
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]