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]

On Jul 20, 2:48 pm, [e-mail] wrote:

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]

<us****@sta.samsung.comwrote in message
news:11**********************@n2g2000hse.googlegro ups.com...

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

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

[Clever Monkey]

us****@sta.samsung.com wrote:

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.
--
clvrmnky <mailto:sp******@clevermonkey.org>

Direct replies will be blacklisted. Replace "spamtrap" with my name to
contact me directly.

[lawrence.jones]

us****@sta.samsung.com wrote:

>
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

[James Kanze]

On Jul 20, 10:12 pm, "Stephen Sprunk" <[e-mail]:

[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 (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 20, 10:50 pm, [e-mail] wrote:

[e-mail] wrote:

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.

Since you're the real expert here: where? In
http://www.mail-archive.com/le******.../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 (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 20, 11:02 pm, Clever Monkey <[e-mail]>
wrote:

[e-mail] wrote:

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_(...wiki/Unix_time

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.)

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Kai-Uwe Bux]

James Kanze wrote:

On Jul 20, 10:50 pm, [e-mail] wrote:

>[e-mail] wrote:

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.

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]

On Jul 22, 2:21 pm, Kai-Uwe Bux <[e-mail]:

James Kanze wrote:

On Jul 20, 10:50 pm, [e-mail] wrote:

[e-mail] wrote:

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.

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/

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:-).)

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Keith Thompson]

James Kanze <ja*********@gmail.comwrites:

On Jul 20, 10:12 pm, "Stephen Sprunk" <[e-mail]:
[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.

[...]

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.

--
Keith Thompson (The_Other_Keith) ks***@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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[James Kanze]

On Jul 22, 10:56 pm, Keith Thompson <[e-mail]:

James Kanze <[e-mail]:

On Jul 20, 10:12 pm, "Stephen Sprunk" <[e-mail]:
[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.

[...]

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]