On my system, a time_t is defined as a long. The struct tm defined in
time.h has the member tm_year declared as an int starting from the year
1900. UNIX timestamps seem to start in January 1st, 1970. Since time_t
is a long, then I would think that we can use negative timestamps to
mean dates previous to 1970. Is there a problem with this that I don't
seem to see?

Why didn't programmers pick the same year to be mark zero in both the
struct tm and the UNIX timestamps? If it's a historical reason, can you
point out any publication that explains the history --- or if not, can
you explain yourself?

Why is the member tm_year defined as an int? Did programmers choose
``int'' in order to allow negative years for some purpose?

Thank you much.

Relevant information about my system:

%grep TIME_T /usr/include/machine/ansi.h
#define	_BSD_TIME_T_	long			/* time()... */

%uname -a
FreeBSD my.free.dom.to 4.11-STABLE FreeBSD 4.11-STABLE #1: Fri Jun 30
01:32:41 EDT 2006 dbastos@my.free.dom.to:/usr/obj/usr/src/sys/LISA i386

[ Post a follow-up to this message ]

Daniel C. Bastos <dbast0s@yahoo.com.br> wrote:
> On my system, a time_t is defined as a long. The struct tm defined in
> time.h has the member tm_year declared as an int starting from the year
> 1900. UNIX timestamps seem to start in January 1st, 1970. Since time_t
> is a long, then I would think that we can use negative timestamps to
> mean dates previous to 1970. Is there a problem with this that I don't
> seem to see?

[url]http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_14[/
url]

If the year is <1970 or the value is negative, the relationship
[between time_t and struct tm] is undefined.

For most implemenation it might work, but that isn't guaranteed.

--
Daniel

[ Post a follow-up to this message ]

> On my system, a time_t is defined as a long. The struct tm defined
> in
> time.h has the member tm_year declared as an int starting from the
> year
> 1900. UNIX timestamps seem to start in January 1st, 1970. Since
> time_t
> is a long, then I would think that we can use negative timestamps to
> mean dates previous to 1970. Is there a problem with this that I
> don't
> seem to see?

MS compilers have an extension called __tm64 and __time_t64 or
something.

> Why didn't programmers pick the same year to be mark zero in both
> the
> struct tm and the UNIX timestamps? If it's a historical reason, can
> you
> point out any publication that explains the history --- or if not,
> can
> you explain yourself?

Because dates before 1970 are of no interrest in computer science.
However years upto 202x (or so) are of interest. You can always
subtract 100 years if you're fine with it. I guess there's a magic
number of years you can shift your system, so the day-names will even
match.


> Why is the member tm_year defined as an int? Did programmers choose
> ``int'' in order to allow negative years for some purpose?

Because int is the fastest processable variable type usually.

[ Post a follow-up to this message ]

"Daniel C. Bastos" <dbast0s@yahoo.com.br> writes:
> On my system, a time_t is defined as a long. The struct tm defined in
> time.h has the member tm_year declared as an int starting from the year
> 1900. UNIX timestamps seem to start in January 1st, 1970. Since time_t
> is a long, then I would think that we can use negative timestamps to
> mean dates previous to 1970. Is there a problem with this that I don't
> seem to see?
>
> Why didn't programmers pick the same year to be mark zero in both the
> struct tm and the UNIX timestamps? If it's a historical reason, can you
> point out any publication that explains the history --- or if not, can
> you explain yourself?
>
> Why is the member tm_year defined as an int? Did programmers choose
> ``int'' in order to allow negative years for some purpose?

Negative timestamps *might* work properly, though there is one
specific negative timestamp, (time_t)-1, that's used to indicate an
error in the time() function.

I suspect that, when tm_year was first defined, it was thought of as
just a 2-digit year.  It probably didn't occur to the authors that
their system would still be in use after 1999.  The only way to make
it consistent was to define it as (year - 1900).  It would have been
more convenient if tm_year had been defined from the beginning as the
full year; int has always been big enough to hold a 4-digit year
number.

time_t is int rather than unsigned int because early versions of C
didn't have unsigned.  (Early C programs actually used char* when they
needed unsigned integers; type checking was much weaker than it is in
modern C.)

1970 was a reasonable epoch for time_t because it was in the recent
past when it was defined.  (I think the epoch was changed several
times before settling on 1970.)  Given 32-bit signed time_t, this
allows times up to 2038 to be represented.  Obviously if nothing is
changed there are going to be serious problems in 2038 -- but that's
32 years away, many systems are already using 64-bit time_t, and I
predict that nearly *all* systems will be using 64-bit signed time_t
well before the deadline (except perhaps for some very old legacy
systems).

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

[ Post a follow-up to this message ]

Daniel C. Bastos wrote:

> On my system, a time_t is defined as a long. The struct tm defined in
> time.h has the member tm_year declared as an int starting from the year
> 1900. UNIX timestamps seem to start in January 1st, 1970. Since time_t
> is a long, then I would think that we can use negative timestamps to
> mean dates previous to 1970. Is there a problem with this that I don't
> seem to see?
>
> Why didn't programmers pick the same year to be mark zero in both the
> struct tm and the UNIX timestamps? If it's a historical reason, can you
> point out any publication that explains the history --- or if not, can
> you explain yourself?
>
> Why is the member tm_year defined as an int? Did programmers choose
> ``int'' in order to allow negative years for some purpose?

I would strongly caution you to use 'time_t' and 'struct tm' only where
needed to interface with system functions that take them or return
them. Otherwise, you should use your own time structures that have
precisely the characteristics you need.

That way you don't have to worry about all this nasty junk. For
example, you don't have to worry about handling times prior to 1/1/70,
since you should never need to pass such a time to the system or get it
back from the system. The same applies for dates after 2038.

DS

[ Post a follow-up to this message ]