In article <397DDAD5.EEA23E94@tribble.com>, David R Tribble
<david@tribble.com> writes
>My model is based on the mktime() call, which "normalizes" the members
>of a broken-down tm struct.  (It's true that I assumed the result
>without actually running a program to confirm it, but based on the
>ISO description, I believe my interpretation is correct.)

The <time.h> stuff is full of holes in the definitions, so there are
lots of places for any interpretation to be wrong. We decided not to
tinker in C99 (I wrote a proposal, but it got dropped) but to let some
experts sort it out properly. I need to chase up the relevant experts in
my copious free time.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet       | Home: <clive@davros.org>
Fax: +44 20 8371 1037 | Thus plc             | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address

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

"blinky" <blinky@nospam.com> writes:
> AFAIK, the Gregorian calendar has a year of 365.2425 days
> (add leap days for +.25, drop century leap days for -.01,
>  add quatracentury leap days for +.0025)
>
> What is 365.2422 ?
>
> (I won't be shocked if the answer has some adjective like 'sidereal' in
> it...)

If I'm not mistaken, 365.2422 is the real-life number to which the
Gregorian 365.2425 is an approximation.  It's the number of solar days
(noon-to-noon) in a tropical year (equinox-to-equinox).

--
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

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

In article <m366pmq6nk.fsf@multivac.student.cwru.edu>,
prj@po.cwru.edu says...
> "blinky" <blinky@nospam.com> writes:
> > What is 365.2422 ?
> >
> > (I won't be shocked if the answer has some adjective like 'sidereal' in
> > it...)
>
> In 24-hour units, it's approximately the length of an astronomical
> (=sidereal) year, - i.e., the length of time it actually takes for the
> earth to go once around the sun.

A sidereal year is exactly the same length as a normal year.  The
sidereal year is simply divided up into one more day than a normal
year.  Thus each sidereal day is a few minutes shorter than a normal
day, but the years are exactly the same length.

--
    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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jerry Coffin <jcoffin@taeus.com> writes:
[...]
> A sidereal year is exactly the same length as a normal year.  The
> sidereal year is simply divided up into one more day than a normal
> year.  Thus each sidereal day is a few minutes shorter than a normal
> day, but the years are exactly the same length.

I don't *think* that's quite correct.  A sidereal year is measured
relative to the "fixed" stars.  A "normal", or tropical, year (i.e.,
the kind to which the calendar is calibrated) is measured from equinox
to equinox.  These differ by about one part in 20,000 (is that the
right number?)  due to the precession of the equinoxes.

The calendar is calibrated to the tropical year because the seasons
are generally more important in every day life than the position of
the sun in the sky relative to the stars, just as we use the solar day
(24 hours, noon to noon) rather than the sidereal day (23h56m4.09s)
which measures the Earth's rotation relative to the stars.

--
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

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

Keith Thompson <kst@cts.com> writes:
> I don't *think* that's quite correct.  A sidereal year is measured
> relative to the "fixed" stars.  A "normal", or tropical, year (i.e.,
> the kind to which the calendar is calibrated) is measured from equinox
> to equinox.  These differ by about one part in 20,000 (is that the
> right number?)  due to the precession of the equinoxes.

ISTR the period of the earth's precession is 26000 years.


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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"David Thompson" <david.thompson1@worldnet.att.net> wrote
 in message news:YwPd5.9294$o71.589627@bgtnsc04-news.ops.worldnet.att.net...
> If you add say 365*10,000 current days worth of microseconds,
> or even 365.2422*10,000, to "now" you arrive at a well-defined
> deterministic value that is unlikely to actually be useful for anything.
>

AFAIK, the Gregorian calendar has a year of 365.2425 days
(add leap days for +.25, drop century leap days for -.01,
 add quatracentury leap days for +.0025)

What is 365.2422 ?

(I won't be shocked if the answer has some adjective like 'sidereal' in
it...)




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

  From: spencer@panix.com (David Spencer)
  Date: Fri, 28 Jul 2000 00:43:23 CST
  Newsgroups: comp.std.c++,comp.std.c

  The standard doesn't require localtime to be meaningful:

I'll say.  The bogus "Date:" line in your posting illustrates this point.
Our news server received your message on at 09:44 CST on July 27, which
is about 16 hours before the message claims it was sent.

The problem is due to a glitch at the comp.std.c++ moderator's server.
Apparently his software thinks that "CST" denotes Australian Central
Standard Time (10 hours ahead of UTC), whereas the relevant Usenet
standard states that "CST" denotes US Central Standard Time (6 hours
behind UTC).  See Internet RFC 1036 section 2.1.2.

This bug affects all the comp.std.c++ postings.  Perhaps our esteemed
moderator can harass his system administrator into fixing this.  But I
agree that that one should not trust localtime and strftime blindly,
nor should one trust timestamps imported from other sources.

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

eggert@twinsun.com (Paul Eggert) writes:

>   From: spencer@panix.com (David Spencer)
>   Date: Fri, 28 Jul 2000 00:43:23 CST
>   Newsgroups: comp.std.c++,comp.std.c
>
>   The standard doesn't require localtime to be meaningful:
>
> I'll say.  The bogus "Date:" line in your posting illustrates this point.
> Our news server received your message on at 09:44 CST on July 27, which
> is about 16 hours before the message claims it was sent.
>
> The problem is due to a glitch at the comp.std.c++ moderator's server.
> Apparently his software thinks that "CST" denotes Australian Central
> Standard Time (10 hours ahead of UTC), whereas the relevant Usenet
> standard states that "CST" denotes US Central Standard Time (6 hours
> behind UTC).  See Internet RFC 1036 section 2.1.2.

Actually, 'CST' is 9:30 or 10:30 ahead of UTC, depending on whether
it's an abbreviation for Central Standard Time or Central Summer Time
(and on the year, half-hours started in 1899).  And there's no easy
way to tell which it is, because the rules are different depending on
which state you're in---NT doesn't have summer time, and the rules for
SA and Broken Hill in NSW differ because of the special rules
introduced in NSW for the olympics.
--
- Geoffrey Keating <geoffk@cygnus.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Anders J. Munch" wrote:
>
> "David R Tribble" <david@tribble.com> wrote:
>>     2000-02-29 + {1y 0m 0d}
>>         = 2001-02-29, normalized to 2001-03-01
>
> What property of real life date and time does this normalization
> proces model?  It seems kinda arbitrary to me.  Why should 2001-02-29
> normalize to 2001-03-01?  The desired result may well have been
> 2001-02-28 (= the last day in February).

My model is based on the mktime() call, which "normalizes" the members
of a broken-down tm struct.  (It's true that I assumed the result
without actually running a program to confirm it, but based on the
ISO description, I believe my interpretation is correct.)

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes:

>Remember that all conforming hosted implementations of ISO C must
>provide the full C library, so it stands to reason to try to find a
>good middle ground between the conflicting goals of 1) providing
>adequate usefulness in the library, and 2) making the library as
>simple and lightweight as possible.

>I suggested that the ISO date/time library functions simply ignore
>leap seconds, in an attempt to meet goal (2) without compromising
>goal (1).  Most applications don't need to account for leap seconds,
>so simply not providing them won't make the functions any less useful
>for most applications, and will make the library code smaller and
>simpler.

Indeed. The most useful incremental addition after the bare minimum
would be to provide local time, but that (the estimable tz) requires a
2MB database that itself requires contant update.

--
dhs spencer@panix.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

spencer@panix.com (David Spencer) writes:

>The most useful incremental addition after the bare minimum
>would be to provide local time,

I don't understand this remark.  C requires localtime.

>but that (the estimable tz) requires a
>2MB database that itself requires contant update.

The database can easily be compressed if needed.
I just compressed the entire database to less than 20kB,
using the shell command:

sed '/^#/d' africa antarctica asia australasia \
 europe northamerica southamerica | bzip2 | wc

A more practical method would probably take more than 20kB,
but not that much more.

Constant update I'll grant you.  But now we have the Internet, and a
protocol has been developed for that (though not widely used yet).

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

eggert@twinsun.com (Paul Eggert) writes:
>spencer@panix.com (David Spencer) writes:
>>The most useful incremental addition after the bare minimum
>>would be to provide local time,

>I don't understand this remark.  C requires localtime.

The standard doesn't require localtime to be meaningful:

"Some functions deal with local time, which is the calendar time
expressed for some specific time zone, and with Daylight Saving Time,
which is a temporary change in the algorithm for determining local
time.  The local time zone and Daylight Saving Time are
implementation-defined."

On every implementation I know, localtime() provides the operating
system's clock time.  On some high-quality operating systems (which do
not include Microsoft Windows and NT), maintained by operators who
keep the database current, that might actually be local time.

However, the standard can't require that.

>>but that (the estimable tz) requires a
>>2MB database that itself requires contant update.

>The database can easily be compressed if needed.
>I just compressed the entire database to less than 20kB,
>using the shell command:

The ability to compress compiled machine-readable data into 20kb is
not the point.  Should the standard require that every implementation
compile that data into every program that uses local time, and provide
the overhead to uncompress, read and interpret it?

Particularly given that the data is going to be wrong before the
implementation -- let alone the program -- is released?

The facilities for keeping a meaningful local time are inherently part
of the execution environment, not the implementation.

>Constant update I'll grant you.  But now we have the Internet, and a
>protocol has been developed for that (though not widely used yet).

Last I looked, the standard didn't require that the execution
environment have facilities for reading the internet.
--
dhs spencer@panix.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

spencer@panix.com (David Spencer) writes:
> Should the standard require that every implementation compile that
> data into every program that uses local time, and provide the
> overhead to uncompress, read and interpret it?

If the standard were to require that this information be available to
programs, it would not require that the information be compiled into
programs.

> The facilities for keeping a meaningful local time are inherently part
> of the execution environment, not the implementation.

The execution environment is part of the implementation.

> >Constant update I'll grant you.  But now we have the Internet, and a
> >protocol has been developed for that (though not widely used yet).
>
> Last I looked, the standard didn't require that the execution
> environment have facilities for reading the internet.

Even if the standard were to require keeping up to date, there's no
reason to require any particular *method* of keeping up to date.


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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

blinky wrote:

> AFAIK, the Gregorian calendar has a year of 365.2425 days
> (add leap days for +.25, drop century leap days for -.01,
>  add quatracentury leap days for +.0025)
>
> What is 365.2422 ?
>
> (I won't be shocked if the answer has some adjective like 'sidereal' in
> it...)

According to _Calendar_ by David Ewing Duncan, the 'true solar year'
has 365.242199 days. This is not the sidereal year, which is the length
of the astronomical year; but rather the 'tropical' year, which is the
mean time between vernal equinoxes. They differ because of the precession
of the equinoxes -- the change in tilt of the earth's axis of rotation.
--
Andy V (OpenGL Alpha Geek)
"In order to make progress, one must leave the door to the unknown ajar."
Richard P. Feynman, quoted by Jagdish Mehra in _The Beat of a Different Drum_.

Paul Martz's OpenGL FAQ: http://www.opengl.org/About/FAQ/Technical.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>
> > The facilities for keeping a meaningful local time are inherently part
> > of the execution environment, not the implementation.
>
> The execution environment is part of the implementation.
>
That's splitting hairs. He intended to underscore the difference between
system code and application code, and make a statement about the duty of the
OS versus the executable.

--
Ken Bloom

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/M/AT/U d- s++:--- a--- C++ UL P++ L+ E----
W+++ N++ ?o ?K w++ !O M++>$ V- PS PE Y-- PGP- t+
5 X++ R--- tv-- b++ DI+ D-- G e- !h r--@ y?
------END GEEK CODE BLOCK------



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

"Ken Bloom" <ken195@bigfoot.com> writes:
> prj@po.cwru.edu (Paul Jarc) writes:
> > spencer@panix.com (David Spencer) writes:
> > > The facilities for keeping a meaningful local time are inherently part
> > > of the execution environment, not the implementation.
> >
> > The execution environment is part of the implementation.
>
> That's splitting hairs. He intended to underscore the difference between
> system code and application code, and make a statement about the duty of the
> OS versus the executable.

If so, then the statement is OT, as it's a matter of implementation
internals, and not of standard conformance.  But I think you're
mistaken; I think DS was saying (incorrectly) that if the standard
required accurate localtime, then the compiler, instead of some other
part of the implementation, would have to provide that facility, and
(correctly) that this would be impractical.  He seemed unaware that
the implementation (as the term is used in the standard) includes not
just the compiler, but the OS, system libraries, etc.


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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"blinky" <blinky@nospam.com> writes:
> What is 365.2422 ?
>
> (I won't be shocked if the answer has some adjective like 'sidereal' in
> it...)

In 24-hour units, it's approximately the length of an astronomical
(=sidereal) year, - i.e., the length of time it actually takes for the
earth to go once around the sun.


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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This discussion of time / date formats seems more appropriate to Cobol,
or databse languages, or even a file system implementation, than to C.

C should provide a selection of integer and floating point variables
which can be used for this, and stop there.

-- William Ehrich



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

Barry Margolin <barmar@genuity.net> writes:

>In article <8l6r7k$1co$1@pegasus.csx.cam.ac.uk>,
>Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>>Two additions with the same type of lapse then commute

>Do they?  What about adding 1 month to August 31, then subtracting 1 month
>from that?  I think you'll end up with either August 30 or September 1,
>depending on how you normalize September 31, but you won't get back to
>August 31.

This is a fairly nasty problem in financial calculations.

For example, LIBOR-based loans or swaps require a page or two of rules
to describe how to determine interest periods (which are denominated
in months).

And most financial instruments have arcane fictions (eg, that a year
is composed of 12 months of 30 days each) that simplified calculations
and permitted use of tables in the pre-computer era.  They can't be
changed, as they are basic assumptions on which people price trillions
of dollars of securities.

Time has been a central part of people's lives for centuries in which
it could only be handled with approximations, simplifications and
rules of thumb.  That makes it complicated enough, even without leap
seconds.

--
dhs spencer@panix.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>> Two additions with the same type of lapse then commute

Barry Margolin <barmar@genuity.net> writes:
>> Do they?  What about adding 1 month to August 31, then subtracting 1
>> month from that?  I think you'll end up with either August 30 or
>> September 1, depending on how you normalize September 31, but you
>> won't get back to August 31.

David Spencer wrote:
> This is a fairly nasty problem in financial calculations.
>
> For example, LIBOR-based loans or swaps require a page or two of rules
> to describe how to determine interest periods (which are denominated
> in months).
>
> And most financial instruments have arcane fictions (eg, that a year
> is composed of 12 months of 30 days each) that simplified calculations
> and permitted use of tables in the pre-computer era.  They can't be
> changed, as they are basic assumptions on which people price trillions
> of dollars of securities.
>
> Time has been a central part of people's lives for centuries in which
> it could only be handled with approximations, simplifications and
> rules of thumb.  That makes it complicated enough, even without leap
> seconds.

Agreed.

Typically these kinds of date calculations (i.e., financial dates)
are provided by specialized applications and libraries.  The date
functions provided by ISO C should be much simpler, and address more
common and unspecialized date computations.

Remember that all conforming hosted implementations of ISO C must
provide the full C library, so it stands to reason to try to find a
good middle ground between the conflicting goals of 1) providing
adequate usefulness in the library, and 2) making the library as
simple and lightweight as possible.

I suggested that the ISO date/time library functions simply ignore
leap seconds, in an attempt to meet goal (2) without compromising
goal (1).  Most applications don't need to account for leap seconds,
so simply not providing them won't make the functions any less useful
for most applications, and will make the library code smaller and
simpler.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

William Ehrich wrote:
> This discussion of time / date formats seems more appropriate to
> Cobol, or databse languages, or even a file system implementation,
> than to C.

Why should C be any less capable of calculating dates and times than
any other language/system?

(FWIW, the other systems you mentioned are usually less capable of
handling dates than C.  And take a guess at how many database and
file systems are written in C.)

> C should provide a selection of integer and floating point variables
> which can be used for this, and stop there.

Used for what, exactly?  The answer to this question is really the
gist of this whole thread: how much functionality should the (new)
ISO C time/date functions cover?

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> wrote :
....
> ... future leap seconds do not occur in
> a linear or predictable fashion (unlike leap days, which follow
> simple rules).  The simplest solution, then, is to choose a time
> representation that ignores leap seconds entirely. ...
> Such a representation, however, can still have as high a resolution
> as one chooses.  E.g., if you choose a representation capable of
> microsecond resolution, you can rely on that fact when you add 365
> days worth of microseconds to one value in order to arrive at another
> (future) time value.
>
The leap-day rules are known (and simple) as long as the Gregorian
calendar applies.  They don't work for most of known history, although
a lot of history more than 1 or 2 centuries ago is not really known to
a day or often even a year anyway.  They won't work more than about
a millenium forward, if we are still living on Earth and organizing
(most) activities according to seasons; if we are living off Earth,
of course, time- and date-keeping will probably be very different.

If you add say 365*10,000 current days worth of microseconds,
or even 365.2422*10,000, to "now" you arrive at a well-defined
deterministic value that is unlikely to actually be useful for anything.

> (IIRC, doesn't the UTC reckoning of time ignore leap seconds, such
> that the current drift between geological TAI time and UTC is now
> about 32 seconds?)
>
UTC includes leap seconds to keep it approximately in sync
with observed astronomical time (UT) and therefore does drift
from TAI, which is atomic.  There is no "geological" time system.

> Most system clocks differ from the international time standard by
> a few seconds or even minutes; do sysadmins update their system
> clocks when a new leap second is decreed?  I doubt it.
>
Those who care about exact time probably NTP from a source
which does it for them.  But for most business and DP uses,
neither leap-second precision nor sub-minute accuracy is needed.

--
- David.Thompson 1 now at worldnet.att.net


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

Fri, 21 Jul 2000 10:21:13 CST, Anders J. Munch <andersjm@post.tele.dk> pisze:

> What property of real life date and time does this normalization
> proces model?  It seems kinda arbitrary to me.  Why should 2001-02-29
> normalize to 2001-03-01?  The desired result may well have been
> 2001-02-28 (= the last day in February).

Because stepping one day at a time should not stop at the end of
the month.

--
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/            GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-

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

"Anders J. Munch" wrote:
>
> "David R Tribble" <david@tribble.com> wrote in message news:3975E06B.8FAE2FBF@tribble.com...
> > Michiel Salters wrote:
> > > That's still not going to solve
> > >
> > >   29-02-2000 + { 1y, 0m, 0d } - { 1y, 0m, 0d },
> > >
> > > is it?
> >
> > Arithmetic operations on dates is a lot like matrix operations, in
> > that they do not obey rules like commutativity and associativity.
>
> IMO good reason to *not* provide such operations as part of the
> standard library.
>
> >     2000-02-29 + {1y 0m 0d}
> >         = 2001-02-29, normalized to 2001-03-01
>
> What property of real life date and time does this normalization
> proces model?  It seems kinda arbitrary to me.  Why should 2001-02-29
> normalize to 2001-03-01?  The desired result may well have been
> 2001-02-28 (= the last day in February).

Well, if you want ultimo arithmetic for date values (bound off the end
of the month), nothing too difficult about that:

2000-02-29 + 1 year (calc last of month again):
2000-03-01 + { 1y, 0m, 0d } - (2000-03-01 - 2000-02-29) = 2001-02-28

Anytime, you want your dates to be end-of-the-month sensitive, you'll
have to do calculations using the first day of the next month and then
subtract the offset.

The nice thing is:
2000-03-31 + 1 month (end of the month):
2000-04-01 + { 0y, 1m, 0d } - (2000-04-01 - 2000-03-31) = 2000-04-30

2000-04-30 + 1 month (end of the month):
2000-05-01 + { 0y, 1m, 0d } - (2000-05-01 - 2000-04-30) = 2000-05-31


Regards,
Heinz

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

In article <3973B10A.DC4B596C@wizard.net>,
James Kuyper  <kuyper@wizard.net> wrote:
>David R Tribble wrote:
>....
>> Most system clocks differ from the international time standard by
>> a few seconds or even minutes; do sysadmins update their system
>> clocks when a new leap second is decreed?  I doubt it.
>
>It's possible, and I believe fairly easy, to set up automatic updates to
>keep in sync with the time standards

So?  Lots of things are easy, but you don't bother because they're not
important.  Outside of some very specialized applications (astronomy, GPS),
clock accuracy within a second is rarely important.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

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

David Tribble writes:
>> E.g., I want the date that is exactly one year from the current date;
>> logically, all I should have to do is add 365 days...

Mark Brader wrote:
> Well, if "the current date" means 2000-07-18, then that's correct.
> But in general...

Yes, I know, adding 365 days to simulate adding one year doesn't
work across leap years.

That's one reason, as I posted previously, that I think we need
standard library function to add and subtract broken-down times.
I.e., one function that allows me to add <1y 0m 0d 0h 0m 0s> to
a given date and return the normalized date (which I can probably
already do using the current <time.h> functions); and another
function that allows me to determine the broken-down difference
between two dates (e.g., the difference between <2000-01-01 00:00:00>
and <2001-01-01 00:00:00> is <1y 0m 0d 0h 0m 0s>, even though the
difference is actually 366 days) (this I cannot do conveniently
with the existing library functions).

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>> E.g., I want the date that is exactly one year from the current date;
>> logically, all I should have to do is add 365 days, but how do I
>> account for possible leap seconds that may or may not occur during
>> the next year?  I can't, because future leap seconds do not occur in
>> a linear or predictable fashion (unlike leap days, which follow
>> simple rules).  The simplest solution, then, is to choose a time
>> representation that ignores leap seconds entirely.

Eric Sosman wrote:
>     The approach is "simple," yes, but it's hardly a "solution."
> For example, it doesn't solve the problem you posed: find the
> date which is exactly one year from the current date.  Run *any*
> proposed solution at 23:59:59 on 31 December, and the presence or
> absence of a leap second can even influence the tm_year field
> (or its analog) of the result.

But you missed my whole point, which was to choose a simple
representation that avoids the entire issue of leap seconds.  If your
time_t doesn't count leap seconds, then adding one year to
CCYY-12-31 23:59:59 always results in a "clean" CCYY-12-31 23:59:59.
No leaps seconds are involved.

>     Simple approaches to this problem are doomed.  Even the most
> complex approaches are unable to solve the generalized problem: as
> someone once pointed out, nobody knows whether New Years' Day of
> AD 1000000 will be a Tuesday.

But you can choose a calendric representation that dictates, in this
current decade, that it will or won't be (e.g., under the current
Gregorian calendar rules, AD1,000,000-01-01 will be a Saturday).
Choosing a relatively simple calendar (or at least one with regular
rules) with which to represent times allows for the most useful
time/date calculations, even if it can't account for all future
calendar changes that are sure to occur beyond the next century.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes:

>difftime(), which
>gives you the difference in seconds as a double value, which is more
>useful and portable (if you don't mind using floating point).

In practice, almost all serious computation using time_t uses signed
integer POSIX time stamps.  I rarely see any serious use of difftime
in real software, and I see a lot of time-related code.

In particular, I would avoid difftime in software intended to be
portable to modern 64-bit POSIX hosts, unless you know that your
timestamps are within a safe range.  For example, in 64-bit Solaris,
time_t and double are both 64-bit types, which means that difftime can
lose information due to rounding error.  Worse, many 64-bit difftime
implementations round incorrectly in some cases.

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

David R Tribble wrote:
>
> >     Simple approaches to this problem are doomed.  Even the most
> > complex approaches are unable to solve the generalized problem: as
> > someone once pointed out, nobody knows whether New Years' Day of
> > AD 1000000 will be a Tuesday.
>
> But you can choose a calendric representation that dictates, in this
> current decade, that it will or won't be (e.g., under the current
> Gregorian calendar rules, AD1,000,000-01-01 will be a Saturday).

Reading this thread, I've thought about the potential usefulness of
keeping inside the date representation weither the date was a future
date, for example a boolean "future" field.

Hum, now that I'm writing this down, I believe,, to be useful, the date
would need to contain the date on which it was calculated! So a date
would be entered as a composite representation of the current date plus
a signed high-precision quantity of seconds "delta" to reach, forward or
backward, the actual desired date. That way, it would be possible to
infer if leap seconds have been added or not. This presents the problem
that a single date may have multiple representations, but for archiving
purpose, date could be normalize to use the same "base time".

Hum, this sounds really like "epoch" and the current time_t. So this
scheme would simply be an extension of the current scheme... which is
good engineering. If the "current date" field is missing, simply use
"epoch".

Alternatively, one could simply keep to number of leap seconds added
since "epoch", so that if that number differs from the official one, one
would know that either the algorithm that calculated the date was not
updated recently or that the date was calculated before the new leap
second(s) were added.

Oh well, if any of this makes sense and would be useful, then I suppose
it has already been patented...

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

Barry Margolin <barmar@genuity.net> writes:

> In article <3973B10A.DC4B596C@wizard.net>,
> James Kuyper  <kuyper@wizard.net> wrote:
> >David R Tribble wrote:
> >....
> >> Most system clocks differ from the international time standard by
> >> a few seconds or even minutes; do sysadmins update their system
> >> clocks when a new leap second is decreed?  I doubt it.

I believe that the NTP protocol does know about leap seconds.  Anyone
not using something like NTP probably couldn't tell if their system
clock was off by one second, since typical computer clocks drift by
more than a second a month anyway.

> >It's possible, and I believe fairly easy, to set up automatic updates to
> >keep in sync with the time standards
>
> So?  Lots of things are easy, but you don't bother because they're not
> important.  Outside of some very specialized applications (astronomy, GPS),
> clock accuracy within a second is rarely important.

And NFS.  The only reason anyone around here cares about the accuracy
of their system clock is so that make works on NFS-mounted filesystems.

--
- Geoffrey Keating <geoffk@cygnus.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:

[ SNIP ]

> That's one reason, as I posted previously, that I think we need
> standard library function to add and subtract broken-down times.
> I.e., one function that allows me to add <1y 0m 0d 0h 0m 0s> to
> a given date and return the normalized date (which I can probably
> already do using the current <time.h> functions); and another
> function that allows me to determine the broken-down difference
> between two dates (e.g., the difference between <2000-01-01 00:00:00>
> and <2001-01-01 00:00:00> is <1y 0m 0d 0h 0m 0s>, even though the
> difference is actually 366 days) (this I cannot do conveniently
> with the existing library functions).

That's still not going to solve

29-02-2000 + { 1y, 0m, 0d } - { 1y, 0m, 0d },

is it?

Or, in words: Just exactly what do you mean with one year later?

Michiel Salters

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

Barry Margolin <barmar@genuity.net> writes:

>Outside of some very specialized applications (astronomy, GPS),
>clock accuracy within a second is rarely important.

I would add "make" (and therefore CVS, RCS, tar, cpio, ...) to that list.
That's why our software development hosts run NTP.

I would also add some financial applications to your list,
e.g. financial trading.

And Kerberos pretty much requires something like NTP,
and NTP needs to handle leap seconds correctly....

Leap seconds aren't just for the astronomers any more.
(Which is why some of the GPS guys are trying to kill off leap seconds....)

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

David R Tribble <david@tribble.com> writes:

>(IIRC, doesn't the UTC reckoning of time ignore leap seconds, such
>that the current drift between geological TAI time and UTC is now
>about 32 seconds?)

The UTC second count ignores leap seconds, which means that the ideal
UTC clock jumps back immediately after an inserted leap second.  To
avoid ambiguity in textual representation, the inserted leap second is
given a different broken-down-time (23:59:60 UTC instead of 00:00:00)

>Most system clocks differ from the international time standard by
>a few seconds or even minutes; do sysadmins update their system
>clocks when a new leap second is decreed?  I doubt it.

This used to be true, but these days a lot of people run NTP or
something similar, and keep their clocks synchronized to within a few
milliseconds of the actual time.  If you count GPS-based units, I'd say
that billions of hosts will care about leap seconds in a few years (or
even months :-) from now.  Leap seconds are no longer just a scientific
curiosity.

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

In article <45%c5.24$A53.352@burlma1-snr2>,
Barry Margolin  <barmar@genuity.net> wrote:
>Outside of some very specialized applications (astronomy, GPS),
>clock accuracy within a second is rarely important.

Another -- and not so specialized -- application which wants synchronized
clocks down to the 1-second-or-better level is multi-processor (parallel)
'make'.

--
-- Jonathan Thornburg <jthorn@thp.univie.ac.at>
   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   "Washing one's hands of the conflict between the powerful and the powerless
    means to side with the powerful, not to be neutral."
                                          -- quote by Freire / poster by Oxfam

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

In article <8l3g9j$5pm$1@set.twinsun.com>,
Paul Eggert <eggert@twinsun.com> wrote:
>And Kerberos pretty much requires something like NTP,
>and NTP needs to handle leap seconds correctly....

I'm pretty sure Kerberos is designed to allow drift of a few seconds.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

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

In article <8l41dc$hmm$1@mach.thp.univie.ac.at>,
jthorn@galileo.thp.univie.ac.at says...
> In article <45%c5.24$A53.352@burlma1-snr2>,
> Barry Margolin  <barmar@genuity.net> wrote:
> >Outside of some very specialized applications (astronomy, GPS),
> >clock accuracy within a second is rarely important.
>
> Another -- and not so specialized -- application which wants synchronized
> clocks down to the 1-second-or-better level is multi-processor (parallel)
> 'make'.

Just FWIW, this is not really the same as clock accuracy.  If all the
clocks were coordinated to say it was presently midnight, June 2,
1892, a parallel make would still be perfectly happy even though this
is obviously extremely inaccurate.  Parallel make requires precision,
but not accuracy.

--
    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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>> That's one reason, as I posted previously, that I think we need
>> standard library function to add and subtract broken-down times.
>> I.e., one function that allows me to add <1y 0m 0d 0h 0m 0s> to
>> a given date and return the normalized date (which I can probably
>> already do using the current <time.h> functions); and another
>> function that allows me to determine the broken-down difference
>> between two dates (e.g., the difference between <2000-01-01 00:00:00>
>> and <2001-01-01 00:00:00> is <1y 0m 0d 0h 0m 0s>, even though the
>> difference is actually 366 days) (this I cannot do conveniently
>> with the existing library functions).

Michiel Salters wrote:
> That's still not going to solve
>
>   29-02-2000 + { 1y, 0m, 0d } - { 1y, 0m, 0d },
>
> is it?

Arithmetic operations on dates is a lot like matrix operations, in
that they do not obey rules like commutativity and associativity.

Your example, for instance, adds a delta time to a date, then
subtracts a delta time, to yield a new date result.  Using the
existing ISO C library, and assuming that date subtraction can be
implemented, we would get these intermediate results:

    2000-02-29 + {1y 0m 0d}
        = 2001-02-29, normalized to 2001-03-01
    2001-03-01 - {1y 0m 0d}
        = 2000-03-01, already normalized

So adding "one year" to 2000-02-29 (a leap day) and then subtracting
"one year" would result in 2000-03-01.  But like I said, don't expect
these operations to obey normal laws of arithmetic, because you're
not dealing with normal arithmetic values.

> Or, in words: Just exactly what do you mean with one year later?

A common concept of "one year later" is to simulate flipping the
pages of a calendar ahead twelve months and pointing to the same
day in the future month as the current day in the present month.
I.e., the simplest concept is "add one to the year", then normalize
the result to allow for leap days and such.

You get into the same problem areas when defining "one month later",
when months obviously don't have the same number of days.  But if
I say "two months from now" and "now" is 2000-07-19, I am pretty safe
in assuming that most people would agree that 2000-09-19 is a
reasonable date to choose.  Dates like 2000-07-31, however, pose a
problem that is best solved, as above, by simply normalizing the
result.

While adding days to a given date is fairly strightforward, adding
things like "90 working days" create problems.  Again, normalize,
normalize, normalize.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>> >     Simple approaches to this problem are doomed.  Even the most
>> > complex approaches are unable to solve the generalized problem: as
>> > someone once pointed out, nobody knows whether New Years' Day of
>> > AD 1000000 will be a Tuesday.

David R Tribble wrote:
>> But you can choose a calendric representation that dictates, in this
>> current decade, that it will or won't be (e.g., under the current
>> Gregorian calendar rules, AD1,000,000-01-01 will be a Saturday).

Pierre Baillargeon wrote:
> Reading this thread, I've thought about the potential usefulness of
> keeping inside the date representation weither the date was a future
> date, for example a boolean "future" field.
>
> Hum, now that I'm writing this down, I believe,, to be useful, the
> date would need to contain the date on which it was calculated! So a
> date would be entered as a composite representation of the current
> date plus a signed high-precision quantity of seconds "delta" to
> reach, forward or backward, the actual desired date. That way, it
> would be possible to infer if leap seconds have been added or not.
> This presents the problem that a single date may have multiple
> representations, but for archiving purpose, date could be normalize
> to use the same "base time".
>
> Hum, this sounds really like "epoch" and the current time_t. So this
> scheme would simply be an extension of the current scheme... which is
> good engineering. If the "current date" field is missing, simply use
> "epoch".
>
> Alternatively, one could simply keep to number of leap seconds added
> since "epoch", so that if that number differs from the official one,
> one would know that either the algorithm that calculated the date was
> not updated recently or that the date was calculated before the new
> leap second(s) were added.

Sounds pretty complicated.  Which is why I reiterate my original
point: Choosing a time representation that doesn't include leap
seconds avoids all of these problems.

Applications that really need to keep track of leap seconds, as
has been pointed out by other posts in this thread, probably do
so using methods that go beyond the ISO C library, which is just
fine.  All other applications, though, can simply ignore leap
seconds.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <jmpuobrs69.fsf@envy.cygnus.com>,
Geoff Keating  <geoffk@cygnus.com> wrote:
>Barry Margolin <barmar@genuity.net> writes:
>> So?  Lots of things are easy, but you don't bother because they're not
>> important.  Outside of some very specialized applications (astronomy, GPS),
>> clock accuracy within a second is rarely important.
>
>And NFS.  The only reason anyone around here cares about the accuracy
>of their system clock is so that make works on NFS-mounted filesystems.

For make, you only need to keep clocks in sync within your LAN; it doesn't
matter whether they're synchronized to a standard timebase, and leap
seconds certainly aren't significant.  You generally don't even need
sub-second accuracy in the synchronization -- a daily "rdate" cron job is
often sufficient.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

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

In article <3975E06B.8FAE2FBF@tribble.com>, David R Tribble <david@tribble.com> writes:
|>
|> Arithmetic operations on dates is a lot like matrix operations, in
|> that they do not obey rules like commutativity and associativity.
|>
|>  ...
|>
|> While adding days to a given date is fairly strightforward, adding
|> things like "90 working days" create problems.  Again, normalize,
|> normalize, normalize.

I disagree that they don't follow normal mathematical rules, provided
that you remember that there are multiple different types of time
lapse - perhaps even an indefinite number.  For example:

    A number of seconds (in astronomical time)
    A number of days in civil time
    A number of working days in context XXX

Two additions with the same type of lapse then commute, but two
additions with different types may not.  All as expected.

The fault with the POSIX model is that it attempts to be all things
to all men.  If the basic time were astronomical, and the context
were attached solely to the time lapse objects and display functions,
there would be no inconsistencies (mathematical or otherwise).

I doubt that there is any chance of this being accepted, though.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

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

In article <djmd5.80$A53.1014@burlma1-snr2>, Barry Margolin <barmar@genuity.net> writes:
|> >
|> >And NFS.  The only reason anyone around here cares about the accuracy
|> >of their system clock is so that make works on NFS-mounted filesystems.
|>
|> For make, you only need to keep clocks in sync within your LAN; it doesn't
|> matter whether they're synchronized to a standard timebase, and leap
|> seconds certainly aren't significant.  You generally don't even need
|> sub-second accuracy in the synchronization -- a daily "rdate" cron job is
|> often sufficient.

Actually, no.  Particularly when cross-compiling, and when tracking
down system problems, drifts of a second or so often cause trouble
and ones of less than a second sometimes do.  This can be more
serious in system administration scripts.  Similarly, a major
discrepancy from 'the outside world' is bad news.  My guidelines
for acceptable drifts in seconds are as follows:

                                           Target      Worst
Within close-coupled systems on a LAN        0.1         1
Separately administered local systems         1         10
Systems run by other organisations           10        100


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

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

David R Tribble wrote:
>
> > Alternatively, one could simply keep to number of leap seconds added
> > since "epoch", so that if that number differs from the official one,
> > one would know that either the algorithm that calculated the date was
> > not updated recently or that the date was calculated before the new
> > leap second(s) were added.
>
> Sounds pretty complicated.  Which is why I reiterate my original
> point: Choosing a time representation that doesn't include leap
> seconds avoids all of these problems.
>
> Applications that really need to keep track of leap seconds, as
> has been pointed out by other posts in this thread, probably do
> so using methods that go beyond the ISO C library, which is just
> fine.  All other applications, though, can simply ignore leap
> seconds.

Well, who is to decide what is complicated? I failed to see why adding a
single field to the current date representation is complicated. If you
don't need it, don't use it, but at least it is standardized. As you
say, all applications that don't need it can ignore it. I see little
point in changing the standard representation of time and come up with
something that is still incomplete.

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

In article <8l6r7k$1co$1@pegasus.csx.cam.ac.uk>,
Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>Two additions with the same type of lapse then commute

Do they?  What about adding 1 month to August 31, then subtracting 1 month
from that?  I think you'll end up with either August 30 or September 1,
depending on how you normalize September 31, but you won't get back to
August 31.

Arithmetic with days, weeks, and units smaller than days work relatively
well because they're fixed units, but months are a big problem because the
time lapse is a function of the starting time.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

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

In article <397700F8.BE97F23E@artquest.net>,
Pierre Baillargeon  <pb@artquest.net> wrote:
>David R Tribble wrote:
>>
>> > Alternatively, one could simply keep to number of leap seconds added
>> > since "epoch", so that if that number differs from the official one,
>> > one would know that either the algorithm that calculated the date was
>> > not updated recently or that the date was calculated before the new
>> > leap second(s) were added.
>>
>> Sounds pretty complicated.  Which is why I reiterate my original
>> point: Choosing a time representation that doesn't include leap
>> seconds avoids all of these problems.
>>
>> Applications that really need to keep track of leap seconds, as
>> has been pointed out by other posts in this thread, probably do
>> so using methods that go beyond the ISO C library, which is just
>> fine.  All other applications, though, can simply ignore leap
>> seconds.
>
>Well, who is to decide what is complicated? I failed to see why adding a
>single field to the current date representation is complicated. If you
>don't need it, don't use it, but at least it is standardized. As you
>say, all applications that don't need it can ignore it. I see little
>point in changing the standard representation of time and come up with
>something that is still incomplete.

The complication isn't in the representation of leap seconds, it's in the
requirement that all conforming implementations must keep track of all leap
seconds that have ever been inserted.  For most purposes this information
is unimportant, so forcing it on all implementations seems excessive.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

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

David R Tribble wrote:
>
> But you missed my whole point, which was to choose a simple
> representation that avoids the entire issue of leap seconds.  If your
> time_t doesn't count leap seconds, then adding one year to
> CCYY-12-31 23:59:59 always results in a "clean" CCYY-12-31 23:59:59.
> No leaps seconds are involved.

    It is obviously impossible for me to judge whether I've missed
your point.  Consider though: If it's worth ignoring leap seconds
in order to simplify the calendar, why stop there?  My modest proposal:

 One minute = 64 seconds
 One hour = 64 minutes
 One day = 32 hours (or 16; I'm open to persuasion)
 One week = 8 days
 One month = 4 weeks
 One year = 16 (or maybe 8) months
 One decade = 8 (16?) years
 One century = 128 years

Such a calendar might be slightly awkward for ordinary uses, but
surely the regularity and simplicity outweigh such mundane concerns.

 Nowadays everyone cool is a Netizen;
 Who cares just when the Sun rises or setzigen?

--
Eric.Sosman@east.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"David R Tribble" <david@tribble.com> wrote in message news:3975E06B.8FAE2FBF@tribble.com...
> Michiel Salters wrote:
> > That's still not going to solve
> >
> >   29-02-2000 + { 1y, 0m, 0d } - { 1y, 0m, 0d },
> >
> > is it?
>
> Arithmetic operations on dates is a lot like matrix operations, in
> that they do not obey rules like commutativity and associativity.

IMO good reason to *not* provide such operations as part of the
standard library.

>     2000-02-29 + {1y 0m 0d}
>         = 2001-02-29, normalized to 2001-03-01

What property of real life date and time does this normalization
proces model?  It seems kinda arbitrary to me.  Why should 2001-02-29
normalize to 2001-03-01?  The desired result may well have been
2001-02-28 (= the last day in February).

--
Anders Munch, andersjm@post.tele.dk
Still confused but at a higher level.


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

David R Tribble <david@tribble.com> suggests:
> Then there are additional library functions that could be added.
> In particular, it would be nice to have a pair of complementary
> functions:
> 1. one determines the difference between two times in broken-down
>  form (e.g., the delta between 2000-01-01 and 2001-01-01 is 1y 1m 1d,
>  which is also 366 days).
> 2. the other adds a delta in broken-down form to a time, yielding
>  a new time (e.g., adding 1y 1m 1d to 2000-01-01 yields 2001-01-01,
>  and adding 0y 0m 366d yields the same).

One of the awkward aspects of the current time_t is that the
difference between two time_t values is a time_t, not a time_diff_t.
A second would be representable as a value of time_diff_t.

Through the wonders of operator overloading and the addition of a
few more types, one can make arithmetic on times account for the
variability in the length of a month, and, given the necessary tables,
the variability in the length of a day.

                                          --Lisa Lippincott

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

In article <p04310103b59543a1252a@[38.168.253.70]>,
lisa_lippincott@bigfix.com says...

[ ... ]

> One of the awkward aspects of the current time_t is that the
> difference between two time_t values is a time_t, not a time_diff_t.

At least as computed by difftime, the difference between two time_t's
is a double.  The only mention of computing differences I see in the
C++ standard is in section 20.5, which basically just refers back to
the C standard (and difftime) for all the details.  Have I missed
something that computes the difference between two time_t's as
another 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

lisa_lippincott@bigfix.com says...
>> One of the awkward aspects of the current time_t is that the
>> difference between two time_t values is a time_t, not a time_diff_t.

Jerry Coffin wrote:
> At least as computed by difftime, the difference between two time_t's
> is a double.  The only mention of computing differences I see in the
> C++ standard is in section 20.5, which basically just refers back to
> the C standard (and difftime) for all the details.  Have I missed
> something that computes the difference between two time_t's as
> another time_t?

    time_t   now = ...;
    time_t   then = ...;

    time_t   diff = (then - now);

The 'diff' value is the difference between two time_t values and is
itself of type time_t.  However, it is pretty much useless unless
you happen to know what representation your local machine uses for
time_t.  All you know is that time_t is arithmetic, which means you
can subtract two time_t values.  But the result may or may not be
meaningful (especially if time_t is actually a set of concatenated
bitfields), and is certainly not portable.

So, no, you haven't missed anything - there is no standard library
function that computes the difference between two time_t values
as a time_t value.  The closest thing we have is difftime(), which
gives you the difference in seconds as a double value, which is more
useful and portable (if you don't mind using floating point).

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>> In particular, I think it would be simpler to have an internal
>> but predictable representation for dates (i.e., a new time_t) which
>> is capable of subsecond resolution and a 1000+ year range, but which
>> does not concern itself with timezones, daylight savings time, or
>> leap seconds.  (Perhaps we could call this new type 'date_t'?)

James Kuyper wrote:
> How could it usefully have subsecond resolution without leap seconds?

There is a difference between resolution and accuracy.  The basic
problem with including leap seconds in any time representation is the
uncertainty incurred when dealing with future time values.

E.g., I want the date that is exactly one year from the current date;
logically, all I should have to do is add 365 days, but how do I
account for possible leap seconds that may or may not occur during
the next year?  I can't, because future leap seconds do not occur in
a linear or predictable fashion (unlike leap days, which follow
simple rules).  The simplest solution, then, is to choose a time
representation that ignores leap seconds entirely.

Such a representation, however, can still have as high a resolution
as one chooses.  E.g., if you choose a representation capable of
microsecond resolution, you can rely on that fact when you add 365
days worth of microseconds to one value in order to arrive at another
(future) time value.

(IIRC, doesn't the UTC reckoning of time ignore leap seconds, such
that the current drift between geological TAI time and UTC is now
about 32 seconds?)

Most system clocks differ from the international time standard by
a few seconds or even minutes; do sysadmins update their system
clocks when a new leap second is decreed?  I doubt it.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
> [...]
> E.g., I want the date that is exactly one year from the current date;
> logically, all I should have to do is add 365 days, but how do I
> account for possible leap seconds that may or may not occur during
> the next year?  I can't, because future leap seconds do not occur in
> a linear or predictable fashion (unlike leap days, which follow
> simple rules).  The simplest solution, then, is to choose a time
> representation that ignores leap seconds entirely.

    The approach is "simple," yes, but it's hardly a "solution."
For example, it doesn't solve the problem you posed: find the
date which is exactly one year from the current date.  Run *any*
proposed solution at 23:59:59 on 31 December, and the presence or
absence of a leap second can even influence the tm_year field
(or its analog) of the result.

    Simple approaches to this problem are doomed.  Even the most
complex approaches are unable to solve the generalized problem: as
someone once pointed out, nobody knows whether New Years' Day of
AD 1000000 will be a Tuesday.

> Most system clocks differ from the international time standard by
> a few seconds or even minutes; do sysadmins update their system
> clocks when a new leap second is decreed?  I doubt it.

    I have no data to support or defend your "most."  However, means
of synchronizing system time to accurate external sources certainly
exist, and I imagine they are well-known to the administrators of
systems where accurate calendars are important.

--
Eric.Sosman@east.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David Tribble writes:
> E.g., I want the date that is exactly one year from the current date;
> logically, all I should have to do is add 365 days...

Well, if "the current date" means 2000-07-18, then that's correct.
But in general...
--
Mark Brader, Toronto            "The language should match the users,
msb@vex.net                      not vice versa"  -- Brian W. Kernighan

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

David R Tribble wrote:
....
> Most system clocks differ from the international time standard by
> a few seconds or even minutes; do sysadmins update their system
> clocks when a new leap second is decreed?  I doubt it.

It's possible, and I believe fairly easy, to set up automatic updates to
keep in sync with the time standards, such as the ones put out by the US
Naval Observatory. I used to have the URL for a freeware product that
promised to synchronize my PC with the USNO each time I booted up.
Unfortunately, it was for the wrong version of Windows.

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

In article <397376B6.BD04388D@east.sun.com>,
Eric Sosman  <Eric.Sosman@east.sun.com> wrote:
>    The approach is "simple," yes, but it's hardly a "solution."
>For example, it doesn't solve the problem you posed: find the
>date which is exactly one year from the current date.  Run *any*
>proposed solution at 23:59:59 on 31 December, and the presence or
>absence of a leap second can even influence the tm_year field
>(or its analog) of the result.

Unless the application is related to astronomy or GPS, it's unlikely that
leap seconds ever make a difference.  In fact, I suspect that most
computers in the world are not synchronized closely to a standard time
base, so even if the date library knew about leap seconds, their clocks are
so far off that they don't matter.  As long as the standard date library
specification has a caveat that it's designed to be sufficient for human
use, but not for astronomical precision, I think most people would be
happy.  The astronomers probably have had time libraries for decades that
work for them, so they can ignore the standard in this regard.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

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

[Subject was: Re: integer types]

David R Tribble <david@tribble.com> writes:
>> And there are probably a few good ideas to borrow from outside C
>> (I'm thinking specifically of Java's Date/Calendar/TimeZone
>> classes).

Paul Eggert wrote:
> Java's TimeZone classes are a good example of what _not_ to do.
> The last time I checked, there was no way to implement accurate time
> zone support that is compatible with Java's TimeZone abstract class.
> This is because the designers of TimeZone didn't understand how
> complicated time zone rules actually are in practice.  Even C89's time
> primitives are better than Java's.

Okay, okay, not all ideas in the Java library are worth stealing;
scratch the TimeZone classes.

But I do like the underlying concept of (but not necessarily the
interface to) Java's Calendar class, which separates time/date
representation from external human representations.  [Making the
point relevant to C again...]  I think it would be useful to look
at other time/date implementations, such as Common LISP and Java,
when we undertake the task of redesigning the C library.

In particular, I think it would be simpler to have an internal
but predictable representation for dates (i.e., a new time_t) which
is capable of subsecond resolution and a 1000+ year range, but which
does not concern itself with timezones, daylight savings time, or
leap seconds.  (Perhaps we could call this new type 'date_t'?)

It seems to be widely accepted that the current time_t definition
is just too vague, so a new definition would require pinning down
a few more details:
A. the range of years it is capable of repesenting (minimum and
  maximum year values), probably as simple macros;
B. the resolution of time it is capable of representing (e.g.,
  ticks per second at its highest resolution), probably as a simple
  macro;
C. a better "error" (or "unknown" or "never") time value.

Such a primitive date value could then be expanded into an
appropriate calendric representation (e.g., good ol' Gregorian),
a la 'struct tm'.  That representation could be further modified
for a given timezone, and further yet for daylight savings time,
and possibly further yet for leap seconds (if we really must).
But only as separate steps; I think the existing tm struct is
too complicated because it attempts to include all three pieces
of information in one single struct, rather than separating them
out for convenience.

Then there are additional library functions that could be added.
In particular, it would be nice to have a pair of complementary
functions:
1. one determines the difference between two times in broken-down
 form (e.g., the delta between 2000-01-01 and 2001-01-01 is 1y 1m 1d,
 which is also 366 days).
2. the other adds a delta in broken-down form to a time, yielding
 a new time (e.g., adding 1y 1m 1d to 2000-01-01 yields 2001-01-01,
 and adding 0y 0m 366d yields the same).

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
....
> In particular, I think it would be simpler to have an internal
> but predictable representation for dates (i.e., a new time_t) which
> is capable of subsecond resolution and a 1000+ year range, but which
> does not concern itself with timezones, daylight savings time, or
> leap seconds.  (Perhaps we could call this new type 'date_t'?)

How could it usefully have subsecond resolution without leap seconds?

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

David R Tribble wrote:
> I think it would be useful to look
> at other time/date implementations, such as Common LISP and Java,
> when we undertake the task of redesigning the C library.

There was a time API working group that was supposed to be working
out a good design; in fact we backed out an attempt at an extended
struct tms and some other supposed improvements when a few problems
surfaced, with the expectation that the working group would get it
right and we could pick up their solution later.  Whatever happened
to them?

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

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

>There was a time API working group that was supposed to be working
>out a good design....  Whatever happened to them?

A mailing list was set up but I never got any email on it.
As far as I know, no progress has been made since the current
proposals on the table:

Bernstein ftp://koobera.math.uic.edu/www/libtai.html
Eggert  http://www.twinsun.com/tz/timeapi.html
Kuhn  http://www.cl.cam.ac.uk/~mgk25/c-time/
Tribble  http://home.flash.net/~dtribble/text/c0xtime.htm

I think that these proposals are all too elaborate and need
simplifying, but it'll take some more experience, consensus-building,
and work.  Bernstein's proposal has the most experience (with real
code), but the least consensus (he's using TAI, which many people find
off-putting).

The POSIX standardization effort has a discussion group
pasc-time-study@opengroup.org also looking at the subject.  Write
Andrew Josey <ajosey@rdg.opengroup.org> to join.  Leading lights of
that group include Markus Kuhn of Cambridge University and Donn Terry
of Microsoft.  The group seems to be leaning toward defining a new time
type (xtime_t, say?), which is arithmetic and which counts some small
fraction of a second (nanoseconds, say?).  However, there's no
commitment yet to try to standardize anything; it's still exploratory.

The two groups should coordinate but as far as I know this hasn't been
done yet.

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