I have been perusing the DWP and have found nothing added to the Standard
C Library for coping with times, in particular a method for computing a
new time by adding an offset to a known time or finding the difference
between two times.

The standard mktime() almost does this well already. The fact that a
"suitable" method already exists is probably why nothing was added to the
standard. However, string<> was added to standardize the many differing
implementations of strings. Lots of vendors provide a custom date/time
object too; why were these classes not also standardized?

The particular problem I run into has to do with daylight savings time. In
places where DST is an issue, there's typically one day of the year that
has two ranges of time from 1am to 2am and another day of the year where
that time range doesn't exist. The standard doesn't seem to address this
issue well. Suppose I use mktime() to create "The first Sunday in April at
1:30am"? Where I live, that time doesn't exist. What does mktime() create?
Or "The first Sunday in November at 1:30am"? Where I live, there are two
possible interpretations of that.

Even worse, suppose I have a struct tm containing "The day before daylight
savings time begins at 12pm." When I add 24 hours to tm_hours and set
tm_isdst to -1, what does mktime() create? The next day at 12pm, 1pm, or
11am? Daylight savings time or not? Which semantics I want probably
depends on whether I'm trying to calculate "1 day from now" or "24 hours
from now."

There has to be some reasonable answer to these questions; why doesn't the
standard address it? Or am I just missing something?

--
Bradd W. Szonye
Doubleplus Corporation
bradds@ix.netcom.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 wrote:
>
> I have been perusing the DWP and have found nothing added to the Standard
> C Library for coping with times, in particular a method for computing a
> new time by adding an offset to a known time or finding the difference
> between two times.
>
> The standard mktime() almost does this well already. The fact that a
> "suitable" method already exists is probably why nothing was added to the
> standard. However, string<> was added to standardize the many differing
> implementations of strings. Lots of vendors provide a custom date/time
> object too; why were these classes not also standardized?

The short answer is, nobody offered a proposal in this area.

> The particular problem I run into has to do with daylight savings time. In
> places where DST is an issue, there's typically one day of the year that
> has two ranges of time from 1am to 2am and another day of the year where
> that time range doesn't exist. The standard doesn't seem to address this
> issue well. Suppose I use mktime() to create "The first Sunday in April at
> 1:30am"? Where I live, that time doesn't exist. What does mktime() create?
> Or "The first Sunday in November at 1:30am"? Where I live, there are two
> possible interpretations of that.
>
> Even worse, suppose I have a struct tm containing "The day before daylight
> savings time begins at 12pm." When I add 24 hours to tm_hours and set
> tm_isdst to -1, what does mktime() create? The next day at 12pm, 1pm, or
> 11am? Daylight savings time or not? Which semantics I want probably
> depends on whether I'm trying to calculate "1 day from now" or "24 hours
> from now."
>
> There has to be some reasonable answer to these questions; why doesn't the
> standard address it? Or am I just missing something?

Date/time types and operations are a nightmare, and daylight savings
time makes it worse.  The Draft C++ library sidesteps most of these

issues by using struct tm to represent dates and times for conversion
to and from text in locale facets time_get<> and time_put<>.  It's
assumed that somebody has a Time class that does the job of converting
to a struct tm representation, and also performs all the daylight savings
time tricks.

A date/time proposal would have to face problems with representation:
does it use a long (with limited range and precision) or something
larger (e.g. a double representing seconds since 1999)?  Some users
of times have to store millions of them and can't afford to "double" the
size.  Should it store local time or GMT?

Daylight savings time is a serious problem: you can't program daylight
savings time rules correctly without frequent access to updates from
the outside world.  The internationalization chapter, Clause 22, is
lacking a timezone facet, partly for this reason, and partly because
(irony filter ON) we didn't have time.

Fortunately (though not by accident) the standard library, and locale in
particular, is extensible, so commercial or free software implementations
of time types and time zone facets are not only reasonable, but welcome.
A timezone facet that checks for updates via the network would solve many
problems.

Nathan Myers
ncm@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                             ]

"Bradd W. Szonye" <bradds@ix.netcom.com> writes:

>I have been perusing the DWP and have found nothing added to the Standard
>C Library for coping with times, ...

The choices confronting the C++ Committee in dealing with the Standard
C library were basically these:
1. Omit it.
2. Include it as-is.
3. Include it with additions and corrections.
4. Include the functionality, but in a C++ style -- redesign and rewrite.

A basic premise for C++ has been characterized: "As close to C as
possible, but no closer." A lodestone has been the traditional
"Hello, world" C program. If that unchanged example isn't valid C++,
the C++ standard would be a failure. More generally, it has been
the case that all the examples in K&R 2 would compile unchanged
by a C++ compiler. That should continue to be true. (I haven't
personally verified the compatibility of K&R 2, but I have been
told it is so.) This premise eliminates options 1 and 4.

The Committee considered whether "fixing" or "improving" the C
library was a good idea. One problem with any changes or
additions is the interaction with the C Standard. We knew that
the C Standard would be up for revision before the C++ Standard
was complete. How could changes be coordinated? How would
disputes between the C and C++ Commitees be resolved? Given that
we want to maintain C and C++ compatibility, it seemed best to
treat the C library as a given, and define the C++ language
and library separately.

In fact, the C++ library contains designs that overlap or replace C
library functionality.  If you like the way the C library works, you
may continue to use it. You can add C++ library features and use
them together: both strings and the C strxxx functions, both
stdio and iostreams, both new/delete and malloc/free, all in
the same program. You can write a C program with a view to
compiling it as a C++ program and not need any conditional code.

Some parts of the C library didn't fit into C++ rules. In some
cases, like setjmp/longjmp, we simply made the effects undefined
if C++ rules happened to be violated by their use. In other
cases, like strchr and strpbrk, the C++ type system was
compromised (and so is the C type system). We found a way to
define those functions in an upward-compatible way. C code
that uses those functions but doesn't violate the type system
will compile unchanged. Those were the extent of the "fixes"
we made: as close to C as possible but no closer.

It would in principle have been possible to add functionality
to the "time.h" part of the C library. But as noted above,
any changes would have to coordinate with the C Committee.
Further, "time.h" is not the C++ way of dealing with time.
Time and Date classes would be the C++ way, but for various
reasons mainly having to do with the amount of work we
felt we could handle, none were defined in this round. By
the next C++ update, enough implementations of various
useful class libraries should be around that we could then
standardize existing library practice.
--
Steve Clamage, stephen.clamage@eng.sun.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
]

On Sunday, April 21, 1996, "Nathan Myers " <ncm@cantrip.org> wrote...
> Bradd W. Szonye wrote:
> >
> > I have been perusing the DWP and have found nothing added to the
Standard
> > C Library for coping with times, in particular a method for computing
a
> > new time by adding an offset to a known time or finding the difference
> > between two times ...
>
> The short answer is, nobody offered a proposal in this area.
>

Duh. The obvious answer--why didn't I think of this myself?

> > The particular problem I run into has to do with daylight savings
time.
> > Where I live, there are two possible interpretations ...
> >
> > Even worse ..., which semantics I want probably
> > depends on whether I'm trying to calculate "1 day from now" or "24
hours
> > from now."
>
> Date/time types and operations are a nightmare, and daylight savings
> time makes it worse.  The Draft C++ library sidesteps most of these
> issues by using struct tm to represent dates and times for conversion
> to and from text in locale facets time_get<> and time_put<>.  It's
> assumed that somebody has a Time class that does the job of converting
> to a struct tm representation, and also performs all the daylight
savings
> time tricks.
>
> A date/time proposal would have to face problems with representation:
> does it use a long (with limited range and precision) or something
> larger (e.g. a double representing seconds since 1999)?  Some users
> of times have to store millions of them and can't afford to "double" the
> size.  Should it store local time or GMT?

This decision was already made for time_t: it's size and locale are
implementation-dependent, and it uses functions to convert it to
meaningful formats. What bothers me is that there's no "defined" way to
calculate one time_t relative to another. A class of size comparable to
time_t (perhaps encapsulating it) with defined arithmetic operators would
do the trick for me.

> Daylight savings time is a serious problem: you can't program daylight
> savings time rules correctly without frequent access to updates from
> the outside world.  The internationalization chapter, Clause 22, is
> lacking a timezone facet, partly for this reason, and partly because
> (irony filter ON) we didn't have time.

Hm... i thought I remembered seeing a timezone facet in one of the 1995
papers. Could be wrong on this. Anyways... I guess it's a bit too late to
make major proposals now, but what I would *like* to have seen is
something like this:

* A class (time_c? name clashes are awful with times) which is a simple
wrapper for the implementation's definition of time_t. If it's not
polymorphic, it would be the same size on most implementations, and you
need a time_t to deal with times anyways.

* A facet or something with DST information and an equivalent to
mktime/localtime/gmtime to convert time_c's to and from struct tm's, to
get the time components

* Possibly classes (year_c, hour_c, second_c, etc.) which can be added to,
subtracted from, etc., a time_c. I'd recommend that adding
hours/seconds/minutes offset the time exactly, while adding
years/months/days would account for DST: ie, 12pm + 1 day is always 12pm
the next day, whereas 12pm + 24 hours might be 1pm the next day if there's
an hour lost to a DST transition. With the current trend toward minimum
32-bit integers, I think it would be reasonable to make these classes
simple wrappers for int. For high-precision time you could allow (time_c +
double) to adjust seconds in floating-point.

It's not the lack of classes that bothers me; it's the complete lack of
handling for DST transitions that bothers me. I struggled with <time.h>
when I learned it (took me forever to learn that mktime and localtime were
inverses) and even now that I'm considerably more sophisticated, this one
issue, lack of time math, still bothers me. It's an important area where
reinventing the wheel and lack of portability is far too easy.

> Fortunately (though not by accident) the standard library, and locale in

> particular, is extensible, so commercial or free software
implementations
> of time types and time zone facets are not only reasonable, but welcome.
> A timezone facet that checks for updates via the network would solve
many
> problems.

Does this mean that Microsoft and Berkeley will set the de facto standards
for desktops and workstations, respectively? Perhaps their implementations
will be written into the official standard when it's renewed in 10 years.


--
Bradd W. Szonye (bradds@ix.netcom.com), Doubleplus Corporation

"To chill or to pop a cap in my dome, whoomp, there it is."
   -- Hamlet, Prince of Denmark



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