Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Question on epoch time

Reply
Thread Tools

Question on epoch time

 
 
usenet@sta.samsung.com
Guest
Posts: n/a
 
      07-20-2007
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

 
Reply With Quote
 
 
 
 
Generic Usenet Account
Guest
Posts: n/a
 
      07-20-2007
On Jul 20, 2:48 pm, (E-Mail Removed) 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.

 
Reply With Quote
 
 
 
 
Stephen Sprunk
Guest
Posts: n/a
 
      07-20-2007
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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

 
Reply With Quote
 
lawrence.jones@ugs.com
Guest
Posts: n/a
 
      07-20-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
Clever Monkey
Guest
Posts: n/a
 
      07-20-2007
(E-Mail Removed) 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 <(E-Mail Removed)>

Direct replies will be blacklisted. Replace "spamtrap" with my name to
contact me directly.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-22-2007
On Jul 20, 9:48 pm, (E-Mail Removed) 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).


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 (Gabi Software) email: (E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-22-2007
On Jul 20, 10:12 pm, "Stephen Sprunk" <(E-Mail Removed)> wrote:

[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: (E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-22-2007
On Jul 20, 10:50 pm, (E-Mail Removed) wrote:
> (E-Mail Removed) 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/leapsecs.../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: (E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-22-2007
On Jul 20, 11:02 pm, Clever Monkey <(E-Mail Removed)>
wrote:
> (E-Mail Removed) 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: (E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      07-22-2007
James Kanze wrote:

> On Jul 20, 10:50 pm, (E-Mail Removed) wrote:
>> (E-Mail Removed) 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Question on epoch time usenet@sta.samsung.com C++ 12 07-23-2007 08:20 AM
covert time from date Hour min sec format to epoch time i.e time since 1 jan 1970 in C Summu82 C Programming 5 06-07-2006 02:51 PM
Time with Epoch earlier than 1970 question Tyler Cruz Perl Misc 4 02-08-2004 09:28 AM
Converting epoch time to "date/time" Marshall Barton NZ Computing 7 02-03-2004 04:29 PM
date and time conversion to EPOCH seconds Rajmohan C Programming 2 07-09-2003 01:17 PM



Advertisments