Question on epoch time

[usenet]

Is the epoch time the number of seconds elapsed since January 1st 1970
in my timezone or as per UTC? I mean, if A's program makes a call to
time() in Melboune and B's program makes a call to time() in Montreal
AT THIS VERY INSTANT, will they return the same values, or will A's
program return a value that is more than B's value by 36000 (since
Melboune is 10 hours ahead of Montreal).

Thanks,
Anil

 

[Generic Usenet Account]

Is the epoch time the number of seconds elapsed since January 1st 1970
in my timezone or as per UTC? I mean, if A's program makes a call to
time() in Melboune and B's program makes a call to time() in Montreal
AT THIS VERY INSTANT, will they return the same values, or will A's
program return a value that is more than B's value by 36000 (since
Melboune is 10 hours ahead of Montreal).

Thanks,
Anil

Sorry, I meant 14 hours ahead.

 

[Stephen Sprunk]

Is the epoch time the number of seconds elapsed since January 1st 1970
in my timezone or as per UTC? I mean, if A's program makes a call to
time() in Melboune and B's program makes a call to time() in Montreal
AT THIS VERY INSTANT, will they return the same values, or will A's
program return a value that is more than B's value by 36000 (since
Melboune is 10 hours ahead of Montreal).

<OT>
It depends, since that's implementation-specific.

The POSIX epoch is defined as 1 Jan 1970 00:00:00 UTC. That's why folks in
the Western Hemisphere occasionally see dates of 31 Dec 1969 in odd places.

The DOS/Windows epoch is, IIRC, 1 Jan 1980 00:00:00 in the local timezone.
</OT>

Relying on there even _being_ an epoch, or that a time_t looks anything like
you expect, is unportable.

S

 

[lawrence.jones]

Is the epoch time the number of seconds elapsed since January 1st 1970
in my timezone or as per UTC?

It's not specified by the C standard, but POSIX defines it to be per
UTC.

-Larry Jones

Some people just don't have inquisitive minds. -- Calvin

 

[Clever Monkey]

Is the epoch time the number of seconds elapsed since January 1st 1970
in my timezone or as per UTC? I mean, if A's program makes a call to
time() in Melboune and B's program makes a call to time() in Montreal
AT THIS VERY INSTANT, will they return the same values, or will A's
program return a value that is more than B's value by 36000 (since
Melboune is 10 hours ahead of Montreal).

http://en.wikipedia.org/wiki/Epoch_(reference_date)
http://en.wikipedia.org/wiki/Unix_time

Pretty complete overview, along with the historical oddities. How
humans compute with time values is an interesting problem to solve
sometimes.

 

[James Kanze]

Is the epoch time the number of seconds elapsed since January 1st 1970
in my timezone or as per UTC? I mean, if A's program makes a call to
time() in Melboune and B's program makes a call to time() in Montreal
AT THIS VERY INSTANT, will they return the same values, or will A's
program return a value that is more than B's value by 36000 (since
Melboune is 10 hours ahead of Montreal).

In C++, there is no "epoch time". All you are guaranteed is
that time_t is an arithmetic type (integral or floating point)
and that the "encoding of the value [returned by time()] is
unspecified". And that you have a certain number of functions
which understand this encoding, in order to convert to/from a
struct tm or to determine the difference in seconds between two
times.

The requirement that time_t be an integral type containing the
number of seconds from some implementation defined "epoch" is
just a frequent convention, not guaranteed either by the C or
C++ standards, nor by Posix. The latter surprized me; I
thought that Posix, or at least X/Open, guaranteed time_t to be
an integral type, with the number of seconds from some
implementation defined epoch, but all I can find in Posix is
"time_t and clock_t shall be integer or real-floating types".
Explicitly not integral, and no mention of any specific
encoding.

Having said that, I've never seen a Unix system where time_t was
anything other than a integral type with the number of seconds
since midnight, January 1st, 1970 UTC (or GMT---I'm not sure
which). (Unix was originally designed as a time sharing system,
in which different users could be in different time zones.)

 

[James Kanze]

[I know that this is off-topic, but...]

The POSIX epoch is defined as 1 Jan 1970 00:00:00 UTC.

Where? I'd always believed that it was implementation defined,
but that time_t was required to contain seconds from some epoch,
but I can't find even that in the on line copy of the Posix
standard.

(It worries me, because I regularly use t1-t2 to get the elapsed
time in seconds, instead of difftime(), when portability is
limited to Unix. And now I learn that even that isn't
portable.)

Relying on there even _being_ an epoch, or that a time_t looks
anything like you expect, is unportable.

So it would seem. For a very large definition of "portable".
(Code that is only portable to Posix compliant C++ compilers is
still "portable". But apparently, this doesn't work even there.)

 

[James Kanze]

(e-mail address removed) wrote:

It's not specified by the C standard, but POSIX defines it to be per
UTC.

Since you're the real expert here: where? In
http://www.mail-archive.com/[email protected]/msg00109.html,
Landon Curt Noll describes what I had always believed to be the
case. (I didn't think that the epoch was fixed, but I definitly
recall the discussions concerning the handling of leap seconds.)
But I simply cannot find it in the on-line Posix standard; in
fact, I find a definite statement that "time_t and clock_t shall
be integer or real-floating types".

 

[James Kanze]

Pretty complete overview, along with the historical oddities. How
humans compute with time values is an interesting problem to solve
sometimes.

Regretfully, the articles just repeat common knowledge, without
citing any real sources, so they don't mean anything. (All too
typical of Wikipedia, I fear.)

 

[Kai-Uwe Bux]

Since you're the real expert here: where?

I would think you find it in Section 4.14 [Seconds Since the Epoch]. See

http://www.opengroup.org/onlinepubs/009695399/


Best

Kai-Uwe Bux

 

[James Kanze]

I would think you find it in Section 4.14 [Seconds Since the Epoch]. See

http://www.opengroup.org/onlinepubs/009695399/

Interesting. Now if there is only some text to somehow relate
time_t to "Seconds Since the Epoch". (The section you mention
doesn't mention time_t at all.)

I'd only looked for the definition of time_t itself before. A
quick search for "epoch" also turns up the specification for
mktime, where it says "The mktime() function shall convert the
broken-down time, expressed as local time, in the structure
pointed to by timeptr, into a time since the Epoch value with
the same encoding as that of the values returned by time()."
And I'm having a hard time figuring out what that is supposed to
mean (although the "with the same encoding as that of the values
returned by time()" certainly suggests that different encodings
are possible).

(Realistically, of course, any Unix system in which time_t was
not an integral value with the number of seconds since the
epoch, or at least since some epoch, would break so many
programs that it wouldn't be used. Or at least, I hope so,
since some of those programs would be my own.)

 

[Keith Thompson]

Where? I'd always believed that it was implementation defined,
but that time_t was required to contain seconds from some epoch,
but I can't find even that in the on line copy of the Posix
standard.

[...]

I'm looking at www.opengroup.org.

The definition of time_t isn't very specific, but the definition of
the time() function says it returns "the value of time in seconds
since the Epoch". The "Epoch" is defined as "The time zero hours,
zero minutes, zero seconds, on January 1, 1970 Coordinated Universal
Time (UTC)."

(I think that UTC wasn't defined until some time after 1970, but I
suppose its definition can be applied retroactively.)

But time_t can be either an integer type (either signed or unsigned)
or a floating-point type.

To maintain some topicality for comp.lang.c, I'll mention (yet again)
that these requirements go beyond what's required by the C standard.

 

[James Kanze]

Where? I'd always believed that it was implementation defined,
but that time_t was required to contain seconds from some epoch,
but I can't find even that in the on line copy of the Posix
standard.

[...]

I'm looking atwww.opengroup.org.

That's my usual source too.

The definition of time_t isn't very specific,

That's putting it mildly.

but the definition of
the time() function says it returns "the value of time in seconds
since the Epoch".

So my next question is why this page didn't turn up when I
searched for "epoch" or "Epoch" at the site. The only page
which did show up was mktime, and that speaks of an "encoding"
for time_t.

My impression is that Posix is rather ambiguous here. I do wish
it would say somewhere that whatever the type, the actual
numeric value in the time_t is the seconds from the epoch.
That's sort of implicit in things like the above---otherwise,
what does "the value of time in seconds since the Epoch" mean?
But if that's the case, why don't the requirements for time_t
say so, and why does the specification of mktime use language
like "with the same encoding as that of the values returned by
time()"?

The "Epoch" is defined as "The time zero hours,
zero minutes, zero seconds, on January 1, 1970 Coordinated Universal
Time (UTC)."

(I think that UTC wasn't defined until some time after 1970, but I
suppose its definition can be applied retroactively.)

It's a different issue, but §4.14 definitly says it is NOT UTC.
In particular, a Posix conformant implementation is required to
ignore leap seconds (except, of course, that there are no fixed
requirements on the accuracy of the clock, so presumably, a
Posix conformant implementation could arrange things so the
clock "just happened" to be off by the amount necessary to take
into account leap seconds).

But time_t can be either an integer type (either signed or
unsigned) or a floating-point type.

But if I take the difference between two type_t, I'll get a
type_t with the number of seconds between the two times. That,
at least, is what I'm looking for; I've always assumed that this
works in a Posix conformant environment (and under more recent
Windows), but I'm have great difficulty finding such a guarantee
in the standard.

To maintain some topicality for comp.lang.c, I'll mention (yet
again) that these requirements go beyond what's required by
the C standard.

Definitly.