In article <3304c8ad.14609390@news.ma.ultranet.com>,
phalpern@truffle.ma.ultranet.com (Pablo Halpern) wrote:

>1. Range (is 1970-2038 enough of a range? Do we need all of history? All
>time since the big-bang?)

Have different classes for absolute time and time difference. The
AbsoluteTime class can store number of seconds as an unsigned 32 bit value
so the range can be 1970..2104. The TimeDifference class uses signed 32
bit (ability to cover half of the range is enough, isn't it?). This
replaces time_t.

Then we can have a class for short times intervalls with high precision,
maybe milliseconds as a signed 32 bit value, the range will then be about
one month which should be enough. This replaces clock_t.

>3. Human interpretation (How long are months? When are the leap years?
>Time zones and daylight savings time. Julian vs. Gregorian calendar.
>Christian, Jewish or Chinese calendar? 12-hour vs. 24-hour clock)

Can't locales be used to solve that?

>  typedef some_type time_diff_t;  // type that can hold time - time val

That should be the TimeDifference class.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <2.2.32.19970129195652.002cf360@central.beasys.com>,
David R Tribble <david.tribble@central.beasys.com> wrote:

>To extend the functionality of the library, rather than just wrapping a
>class around it, it would be nice to have some useful additions:

First of all, we should require some functionality that <time.h> use to
have but the standard doesn't actually require. Such as at least second
resolution a minimal range.

>    Time/date computations, as alluded to in the above class, such as:
>
>        Add a signed number of microseconds/seconds/minutes/days/months/years
>        to a time.  (True, we must define what adding a month to 1997/01/31
>        or adding a year to 1996/02/29 means, but there's at least one good
>        answer to these.)
>
>        Find the (signed?) difference between two times (stored in a DateTime
>        format).  (BTW, that's why time_t is a signed value; subtracting
>        today's date from yesterday's should result in a negative time_t
>        value.)
>
>        Compare two times.  This is probably best done by overloading
>        operator <() et al.

Maybe we should have two classes, one for absolute time and one for
realtive time (time difference).

class DateTime; // can be unsigned
class TimeDiff; // must be signed

>Not to mention something like strftime() for strings.

We should have operator<< overloaded to output a nice locale dependent
string representation. For the standard "C" locale, the format should be
ISO rather than the braindead ctime() format.


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

I (David R. Tribble <david.tribble@central.beasys.com>) wrote:
>To extend the functionality of the library, rather than just wrapping a
>class around it, it would be nice to have some useful additions:
>
>    Subsecond accuracy.  Say, to the nearest microsecond (if the O/S can
>    provide it, otherwise let usec=0).  UNIX has a 'timeval' struct that
>    encodes the time as seconds (time_t) and microseconds (32-bit int)
>    which is accurate to the nearest O/S clock tick (typically .01 sec).

Bill Vaughan <bill@osisoft.com> responded:
> The best way to do this would be to make seconds a floating-point
> quantity. This avoids messy conflicts between systems that report
> milliseconds, those that report microseconds, those that report ticks,
> and those that cannot handle high-precision time.

I disagree.  What I had in mind was a simple DateTime base class that gives
the date & time to the nearest second (ala the POSIX time_t type).  For
subsecond accuracy, I think a derived type that adds a member for extra
precision is fine; I had in mind a 32-bit integer that represents the
number of microseconds.  For systems that can't do subsecond times, this
member's value would always be zero; for those that can, it would be the
smallest practical unit of time (such as the system clock tick interval,
which is typically the ANSI CLOCKS_PER_SEC macro value) rounded off to the
nearest microsecond.  That way you get a standard time representation no
matter what O/S you're on.

As Pete Forman <gsez020@megan.bedford.waii.com> pointed out, there is a
difference in 'precision' and 'accuracy'.  I desire the subsecond precision
to be microseconds and the accuracy to be whatever the O/S can deliver.

Nanoseconds is also a good choice, since it would also fit into a 32-bit
integer.

I don't like incurring the overhead of floating point unless I really, really
have to.

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

In article <2.2.32.19970131004635.002c0e18@central.beasys.com>, David R
Tribble <david.tribble@central.beasys.com> wrote:

>What I had in mind was a simple DateTime base class that gives
> the date & time to the nearest second (ala the POSIX time_t type).  For
> subsecond accuracy, I think a derived type that adds a member for extra
> precision is fine; I had in mind a 32-bit integer that represents the
> number of microseconds.  For systems that can't do subsecond times, this
> member's value would always be zero; for those that can, it would be the
> smallest practical unit of time (such as the system clock tick interval,
> which is typically the ANSI CLOCKS_PER_SEC macro value) rounded off to the
> nearest microsecond.  That way you get a standard time representation no
> matter what O/S you're on.
>
> As Pete Forman <gsez020@megan.bedford.waii.com> pointed out, there is a
> difference in 'precision' and 'accuracy'.  I desire the subsecond precision
> to be microseconds and the accuracy to be whatever the O/S can deliver.
>
> Nanoseconds is also a good choice, since it would also fit into a 32-bit
> integer.
>
> I don't like incurring the overhead of floating point unless I really, really
> have to.

If there are any additions, then I would strongly suggest something that
will not stop working in my life time or my grandchildrens lifetime. For
example like this:

   typedef struct {
      seconds_t      seconds;
      subseconds_t   subseconds;
   } DateTime;

together with a macro for the subseconds resolution

   #define SUBSECONDS_PER_SEC

which does not have to be a compile-time constant but could be implemented
as a function or extern variable, and _a guarantee_ that any date from
lets say 1601 to 2399 can be represented exactly by the "seconds" value. I
personally dont care if this requires floating point for the 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         ]
[ 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                             ]