time_t in seconds

[j0mbolar]

i've read recently that time_t doesn't have to be in second resolution
but if it isn't, then what resolution could it be in?

microseconds, milliseconds, are all valid?

also, does anyone know of an implementation
that does not use second resolution for a time_t?

[Martin Ambuhl]

j0mbolar wrote:

i've read recently that time_t doesn't have to be in second resolution
but if it isn't, then what resolution could it be in?

microseconds, milliseconds, are all valid?

It doesn't have to even be a linear metric.

[Gordon Burditt]

>i've read recently that time_t doesn't have to be in second resolution

but if it isn't, then what resolution could it be in?
time_t is not required to be represented as a number of <time unit>
since <epoch>. That said, if it IS represented as a number of <time
unit> since <epoch>, any time unit, regardless of how silly, and
any epoch is acceptable. It is a quality-of-implementation issue
that times near to now should be representable, and with fairly
decent resolution (an 8-bit integer counter of geologic ages would
be considered poor here, as would a 32-bit number of picoseconds
since the beginning of the universe. Putting the epoch at the END
of the universe is also problematical since I don't think anyone
knows when that is relative to now. The same applies to putting
it as the day of the assassination of World President Saddam Hussein).

One possible representation of time_t is:
hhHHSSMMmmddyyyy
substitute decimal digits for the values, then treat it as a decimal
integer. A time_t needs more than 48 bits for this representation.
yyyy = year (Y10K problem here!!)
mm = month (1-12)
dd = day of month (1-31)
HH = hour (0-24)[*]
MM = minute (0-60)[*]
SS = second (0-60)[*]
hh = hundredths of seconds (0-99)
[*] Some of these limits may seem a bit strange to allow for
leap seconds.

Note that the fields are put in a decidedly non-endian order, so
the result you get from adding or subtracting them is essentially
useless, and even comparing them as integers doesn't tell you which
comes first unless they happen to both be in the same second.
microseconds, milliseconds, are all valid?
Yes, as are nano-fortnights and a big integer type that packs the
28 characters of "Sat Apr 17 19:58:47 CDT 2004" into it.
also, does anyone know of an implementation
that does not use second resolution for a time_t?

Microsoft systems such as MS-DOS used a bitfield representation of
year, month, day, hour, minute, and seconds for file date
representations. I don't think they used it as a time_t, though.
BSD Unix systems also have a struct timeval which typically contains
a time_t and a counter for fractions of seconds. That also isn't
actually used as a time_t.

Gordon L. Burditt

[Keith Thompson]

go***********@burditt.org.org (Gordon Burditt) writes:
[...]

One possible representation of time_t is:
hhHHSSMMmmddyyyy
substitute decimal digits for the values, then treat it as a decimal
integer. A time_t needs more than 48 bits for this representation.
yyyy = year (Y10K problem here!!)
mm = month (1-12)
dd = day of month (1-31)
HH = hour (0-24)[*]
MM = minute (0-60)[*]
SS = second (0-60)[*]
hh = hundredths of seconds (0-99)

[*] Some of these limits may seem a bit strange to allow for
leap seconds.

Small quibble: to allow for leap seconds, it's sufficient to make the
range of SS 0-60; MM can be 0-59, and HH can be 0-23.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Simon Biber]

"Gordon Burditt" <go***********@burditt.org.org> wrote:

One possible representation of time_t is:
hhHHSSMMmmddyyyy
substitute decimal digits for the values, then treat it as a decimal
integer. A time_t needs more than 48 bits for this representation.
yyyy = year (Y10K problem here!!)
mm = month (1-12)
dd = day of month (1-31)
HH = hour (0-24)[*]
MM = minute (0-60)[*]
SS = second (0-60)[*]
hh = hundredths of seconds (0-99)

typedef long long time_t;

double difftime(time_t a, time_t b)
{
double year = (a % 10000
- b % 10000) * 31556952.0;
double month = (a % 100000000 / 1000000
- b % 100000000 / 1000000) * 2629746.0;
double day = (a % 1000000 / 10000
- b % 1000000 / 10000) * 86400.0;
double hour = (a % 100000000000000 / 1000000000000
- b % 100000000000000 / 1000000000000) * 3600.0;
double minute = (a % 10000000000 / 100000000
- b % 10000000000 / 100000000) * 60.0;
double second = (a % 1000000000000 / 10000000000
- b % 1000000000000 / 10000000000);
double hundredth = (a / 100000000000000
- b / 100000000000000) / 100.0;
return year + month + day + hour + minute + second + hundredth;
}

The values for month and year are for an average year, but they should
actually depend on the year in question. Argh!

--
Simon.

[Peter Pichler]

"Gordon Burditt" <go***********@burditt.org.org> wrote:

One possible representation of time_t is:
hhHHSSMMmmddyyyy .... yyyy = year (Y10K problem here!!)
mm = month (1-12)
dd = day of month (1-31)
HH = hour (0-24)[*]
MM = minute (0-60)[*]
SS = second (0-60)[*]
hh = hundredths of seconds (0-99) .... Note that the fields are put in a decidedly non-endian order

Isn't there a precedent for this representation already? :-)

microseconds, milliseconds, are all valid?

Yes, as are nano-fortnights and a big integer type that packs the
28 characters of "Sat Apr 17 19:58:47 CDT 2004" into it.

A colleague of mine has had a teacher of physics who insisted on
converting everything to elementary units.

Stones, furlongs and fortnights.

Peter

[Dan Pop]

In <2d**************************@posting.google.com > j0******@engineer.com (j0mbolar) writes:

also, does anyone know of an implementation
that does not use second resolution for a time_t?

I have yet to hear about one. I guess there was far too much existing
practice in having time_t as a second offset from one epoch or another
(the MSDOS epoch used to be 1980.1.1 on the early implementations, IIRC)
that no one (or practically no one) bothered to reinvent this wheel.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de