Normalizing tm structure past 2038

[Stu]

Does any body have any "C" code, which there willing to share, that
can normalize a tm structure, which goes past the 2038 EPOCH.

For example,

I have the following tm stucture, which is set to the EPOCH
/* Tue Jan 19 03:14:07 2038 */

epoch = {
tm_sec = 7
tm_min = 14
tm_hour = 3
tm_mday = 19
tm_mon = 0
tm_year = 138
tm_wday = 0
tm_yday = 19
tm_isdst = 0
}

I want to be able to increment epoch.tm_mday by "n" # of days and than
pass it to a function like strftime() (see below) and have the
correct date print out.

if (strftime (buf, sizeof(buf), "%Y.%m.%d %H:%M:%S", epoch) > 0)
printf ("Retention Expiration = %s\n", buf );

Thanks in advance for all the answer this post.

 

[Mark McIntyre]

I want to be able to increment epoch.tm_mday by "n" # of days and than
pass it to a function like strftime() (see below) and have the
correct date print out.

I don't believe you can do this, unless your implementation supports
dates beyond 2038 in its implementation of time_t etc. Clearly yours
doesn't. You would be better off asking in a group specialising in
your system tho.

 

[August Derleth]

Does any body have any "C" code, which there willing to share, that
can normalize a tm structure, which goes past the 2038 EPOCH.

The epoch isn't 2038. The epoch is when the clock /began/, not when it
/ends/ (or, more appropriately, when it fails). The C Standard is
silent on the issue of when any OS's internal clock's representation
of time begins or ends.

BTW, not every OS has an epoch. Some OSes don't care about time at
all. Some use a clock system that doesn't have an epoch. The idea
you're discussing is quite specific to Unix and Unix-like OSes.
Therefore, it is off-topic here.*

*If the Standard does, indeed, specify an epoch-based concept of time,
someone please correct me. But (IME) that would be contra the spirit
of the Standard and quite unlikely.

 

[Richard Heathfield]

August Derleth wrote:

BTW, not every OS has an epoch. Some OSes don't care about time at
all. Some use a clock system that doesn't have an epoch. The idea
you're discussing is quite specific to Unix and Unix-like OSes.
Therefore, it is off-topic here.*

*If the Standard does, indeed, specify an epoch-based concept of time,
someone please correct me. But (IME) that would be contra the spirit
of the Standard and quite unlikely.

You're correct. "The time function determines the current calendar time. The
encoding of the value is unspecified."

The closest you get to an epoch in C is 1900. In struct tm, the year is:

"int tm_year; /* years since 1900 */"

So this is year 103 (that is, the one hundred and fourth year!) of the C
epoch, which will last at least until the year 34666.

 

[Simon Biber]

BTW, not every OS has an epoch. Some OSes don't care about time at
all. Some use a clock system that doesn't have an epoch. The idea
you're discussing is quite specific to Unix and Unix-like OSes.
Therefore, it is off-topic here.*

*If the Standard does, indeed, specify an epoch-based concept of
time, someone please correct me. But (IME) that would be contra
the spirit of the Standard and quite unlikely.

Indeed, the Standard does not require an epoch-based concept of
time.

One of my systems does have an Epoch, but specifies time_t as a
signed long long value representing the number of milliseconds
before or after the Epoch. It can represent dates more than two
hundred million years in the future or past.

Another system encodes Year, Month, Day, etc as separate bitfields
within the representation of the time_t value.

 

[Chris Torek]

... The C Standard is silent on the issue of when any OS's
internal clock's representation of time begins or ends.

Which, alas, makes the time_t type not nearly as useful as it might
be. But then, keeping track of time is surprisingly difficult; it
may be for the best that the C standard does not try to address
the problems. (The simplest solution by far is to decree that
everyone shall use TAI -- atomic time as defined internationally
-- but this is not backwards-compatible with existing systems.)

*If the Standard does, indeed, specify an epoch-based concept of time,
someone please correct me. But (IME) that would be contra the spirit
of the Standard and quite unlikely.

The C standards do not, but it is pretty common. At least one
"add-on" standard (POSIX P1003.x) does set the 1 Jan 1970 epoch
in stone, and any C system that uses this and has a 32-bit
signed integer "seconds since 1970" counter will have the "Y2038
bug". It is easy enough to extend it another 68 years (by going
to unsigned 32-bit integers), but better to go to a 64-bit type.