«

In article <>,
Keith Thompson <kst-> wrote:
>William Ahern <> writes:
>[...]
>> I should note that encoding leap seconds into time_t is inherently fuzzy,
>> because you cannot reliably predict leap seconds into the future. That makes
>> difftime() calculations indeterminate for dates merely years into the
>> future. (And perhaps partly explains why there's no strptime or timegm in
>> C.) For example, global climate change will unpredictably effect the earth's
>> rotation as the mass of water from the poles moves toward the equator. That
>> will accelerate the earth's shift to being tidally locked with the Sun
>> (notwithstanding it being incinerated before then). Changes in earth's core
>> as well as various tectonic events also unpredictably accelerate and
>> declerate the Earth's rotation. Even if these changes are too small to add
>> or subtract an entire second, they certainly shift the onset of the next
>> leap second.
>[...]
>
>Earth is expected to become tidally locked with the Moon, not the Sun.

Is that what the C standard says?

If so (if that is what you are claiming), then chapter & verse, please?

--
Those on the right constantly remind us that America is not a
democracy; now they claim that Obama is a threat to democracy.

On Wed, 06 Feb 2013 13:16:03 -0800, Keith Thompson <kst-> wrote:

>Earth is expected to become tidally locked with the Moon, not the Sun.
>

http://xkcd.com/386/

Geoff <> writes:
> On Wed, 06 Feb 2013 13:16:03 -0800, Keith Thompson <kst-> wrote:
>>Earth is expected to become tidally locked with the Moon, not the Sun.
>
> http://xkcd.com/386/

Yeah, I suppose it's a little scary that I don't have to follow the link
to know which cartoon it is.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Wed, 06 Feb 2013 18:15:46 -0800, Keith Thompson <kst-> wrote:

>Geoff <> writes:
>> On Wed, 06 Feb 2013 13:16:03 -0800, Keith Thompson <kst-> wrote:
>>>Earth is expected to become tidally locked with the Moon, not the Sun.
>>
>> http://xkcd.com/386/
>
>Yeah, I suppose it's a little scary that I don't have to follow the link
>to know which cartoon it is.

I got a nice chuckle out of this. But it's no more scary than the fact I could
type it from memory.

Enjoy.

On Feb 5, 6:02*pm, Francois Grieu <fgr...@gmail.com> wrote:
> The gmtime function in header <time.h>
> converts the calendar time pointed to by some
> pointer to time_t into a broken-down time,
> expressed as UTC.
>
> Is there a canonical way to do the reverse?

As long as you have a simple way to compare the
outputs of gmtime for before/after time-wise
(e.g. by using strcmp() after expressing them in
YYYY-MM-DDThh:mm:ss format), then there is a simple
solution based on binary search -- move a bit through
the (32?) bis of the input to gmtime(); call gmtime()
for each bit; compare the result to your target;
discard or keep the bit depending on the compare result.
May sound brutal, but it's a happy way, at least
if you don't let it get to be a habit.

<BORING anecdote> I did it this way 38 years ago to set the system
clock in a diagnostic program. Why did the diagnostic
need to set the clock correctly? The clock could have four
states
* Set to correct date
* Set to incorrect date
* Not set
* In "error" state
Machines normally powered up "Not set" which was usable --
the clock could be used for the comparative timings I needed
even though absolute time was wrong. But a hardware glitch
sometimes moved the clock to the unusable "error" state,
from which it could be changed to "Set" but not "Not set."

And then setting the clock to an INCORRECT value was a poor option.
Since the clock was "Set", the IBM MVS operating system would
blithely go forth without giving operator the option of changing
the date ... and then crash when it belatedly discovered the
date made no sense. ::whack::
There was an operator workaround, but the junior operators
on graveyard shift didn't know it, and that's when we perverse
nerds usually got our paws on the mainframe....
</boring anecdote>

James

On Feb 7, 4:49*am, Eric Sosman <esos...@comcast-dot-net.invalid>
wrote:
> On 2/6/2013 4:16 PM, Keith Thompson wrote:
>
>
>
>
>
>
>
>
>
> > William Ahern <will...@wilbur.25thandClement.com> writes:
> > [...]
> >> I should note that encoding leap seconds into time_t is inherently fuzzy,
> >> because you cannot reliably predict leap seconds into the future. Thatmakes
> >> difftime() calculations indeterminate for dates merely years into the
> >> future. (And perhaps partly explains why there's no strptime or timegmin
> >> C.) For example, global climate change will unpredictably effect the earth's
> >> rotation as the mass of water from the poles moves toward the equator.That
> >> will accelerate the earth's shift to being tidally locked with the Sun
> >> (notwithstanding it being incinerated before then). Changes in earth'score
> >> as well as various tectonic events also unpredictably accelerate and
> >> declerate the Earth's rotation. Even if these changes are too small toadd
> >> or subtract an entire second, they certainly shift the onset of the next
> >> leap second.
> > [...]
>
> > Earth is expected to become tidally locked with the Moon, not the Sun.
>
> * * *... in January 2038, right?
>
> --
> Eric Sosman
> esos...@comcast-dot-net.invalid

On Feb 7, 4:49*am, Eric Sosman <esos...@comcast-dot-net.invalid>
wrote:
> On 2/6/2013 4:16 PM, Keith Thompson wrote:
> > Earth is expected to become tidally locked with the Moon, not the Sun.
>
> * * *... in January 2038, right?

Humanity survived the Cuban Missile Crisis (allegedly
a much closer thing than was revealed at the time);
we survived the Mayan Apocalypse; we even survived the
Janet Jackson wardrobe malfunction. But we we survive
the 68 years of Darkness caused by the Unix clock?

I think The Committee has rejected my suggestion:
to subtract 66.6 years and start a new epoch:
Anno Diaboli


(PS: I didn't want to post this, but clicked Send accidentally.)

James

On 13-02-06 09:56 AM, Keith Thompson wrote:
> Francois Grieu <> writes:
>> On 05/02/2013 20:56, William Ahern wrote:
>> > Francois Grieu <> wrote:
>> >> The gmtime function in header <time.h>
>> >> converts the calendar time pointed to by some
>> >> pointer to time_t into a broken-down time,
>> >> expressed as UTC.
>> >
>> >> Is there a canonical way to do the reverse?
>> >
>> > No. Many systems have timegm(3) (Linux, *BSD, OS X), but many don't
>> > (Solaris, Windows).
>>
>> Indeed there is no such function. I hoped there was a
>> consensus on a portable method.
>
> For restricted values of "consensus" and "portable":
>
> My Linux system has timegm(). Here's an excerpt from the man page (also
> available at
> <http://www.kernel.org/doc/man-pages/online/pages/man3/timegm.3.html>):
>
> NOTES
> The timelocal() function is equivalent to the POSIX standard
> function mktime(3). There is no reason to ever use it.
>
> For a portable version of timegm(), set the TZ environment
> variable to UTC, call mktime(3) and restore the value of TZ.
> Something like
>
> #include <time.h>
> #include <stdlib.h>
>
> time_t
> my_timegm(struct tm *tm)
> {
> time_t ret;
> char *tz;
>
> tz = getenv("TZ");
> setenv("TZ", "", 1);
> tzset();
> ret = mktime(tm);
> if (tz)
> setenv("TZ", tz, 1);
> else
> unsetenv("TZ");
> tzset();
> return ret;
> }
>
> My own notes on the above:
>
> I'm not sure why it refers to mktime() as a "POSIX standard function".
> It is, but it's also defined by the C standard.
>
> The assumption that the time zone is controlled by the "TZ" environment
> variable, and the existence of the setenv() and unsetenv() functions,
> are portable to POSIX systems, but not to C implementations in general.
>
> [...]
>> I'm reading the C standard as allowing time_t to be e.g.
>> a 64-bit type with the date and time BCD-coded as read from
>> a physical clock IC such as
>> http://datasheets.maximintegrated.com/en/ds/DS1375.pdf
>> If that's the case, we can not even count on the linearity of
>> difftime.
>
> That's correct. clock_t and time_t are merely "real types capable
> of representing times"; nothing more is guaranteed.
>



I'm wrestling with this a little bit. Since "time_t = time(time_t)"
returns the number of seconds since the epoch, which is, as I understand
it, "1970-01-01 00:00:00 +0000 (UTC)", why is it in local time in the
example below? If time_t values were *always* specific to the epoch
_UTC_ then it would seem to simplify things.

I realize that this is going to be affected by the bios clock but in my
case the bios clock is set to UTC.

Is the lack of a TZ field in the struct tm an oversight?


greg@satellite:~/devel/tests/c$ ./tm_test
now = 1360256972
PST 1360256972
UTC : 1360228172
greg@satellite:~/devel/tests/c$ date
Thu Feb 7 09:09:36 PST 2013

// the program

#define _XOPEN_SOURCE 700

#include <time.h>
#include <stdlib.h>
#include <stdio.h>

time_t tz_mktime (const char* const tz, struct tm* t) {
setenv ("TZ", tz, 1);
tzset ();

return mktime (t);
}

int main () {
time_t now = time (NULL);
struct tm* t = localtime (&now);
char *tz = getenv ("TZ");

printf ("now = %lu\n", (unsigned long int) now);


time_t tzt;

if (tz) {
tzt = tz_mktime (tz, t);
printf ("%s %lu\n", tz, (unsigned long int) tzt);
} else {
tzt = tz_mktime ("PST8PST", t);
printf ("PST %lu\n", (unsigned long int) tzt);
}

tzt = tz_mktime ("", t);
printf ("UTC : %lu\n", (unsigned long int)tzt);

if (tz) {
setenv ("TZ", tz, 1);
} else {
unsetenv ("TZ");
}

tzset ();

return 0;

}

Greg Martin <> writes:
[...]
> I'm wrestling with this a little bit. Since "time_t = time(time_t)"
> returns the number of seconds since the epoch, which is, as I understand
> it, "1970-01-01 00:00:00 +0000 (UTC)", why is it in local time in the
> example below? If time_t values were *always* specific to the epoch
> _UTC_ then it would seem to simplify things.
>
> I realize that this is going to be affected by the bios clock but in my
> case the bios clock is set to UTC.

The following is applicable to POSIX systems, where a time_t value
represents seconds since the epoch. C makes no such guarantee.

A time_t value *always* represents seconds since the "epoch', which is
defined as 1970-01-01 00:00:00 UTC. It never refers to local time.
(Well, it can refer to anything you like, but C or POSIX standard
functions that deal with time_t values treat them as seconds since the
epoch, as defined above.) (I'm ignoring leap seconds.)

> greg@satellite:~/devel/tests/c$ ./tm_test
> now = 1360256972
> PST 1360256972
> UTC : 1360228172
> greg@satellite:~/devel/tests/c$ date
> Thu Feb 7 09:09:36 PST 2013
>
> // the program
>
> #define _XOPEN_SOURCE 700
>
> #include <time.h>
> #include <stdlib.h>
> #include <stdio.h>
>
> time_t tz_mktime (const char* const tz, struct tm* t) {
> setenv ("TZ", tz, 1);
> tzset ();
>
> return mktime (t);
> }
>
> int main () {
> time_t now = time (NULL);
> struct tm* t = localtime (&now);
> char *tz = getenv ("TZ");
>
> printf ("now = %lu\n", (unsigned long int) now);
>
>
> time_t tzt;
>
> if (tz) {
> tzt = tz_mktime (tz, t);
> printf ("%s %lu\n", tz, (unsigned long int) tzt);
> } else {
> tzt = tz_mktime ("PST8PST", t);
> printf ("PST %lu\n", (unsigned long int) tzt);
> }
>
> tzt = tz_mktime ("", t);
> printf ("UTC : %lu\n", (unsigned long int)tzt);
>
> if (tz) {
> setenv ("TZ", tz, 1);
> } else {
> unsetenv ("TZ");
> }
>
> tzset ();
>
> return 0;
>
> }

In your program, you compute a struct tm value by calling localtime()
with a time_t value returned by time(). That struct tm value refers to
the local time, not UTC.

For example, as I'm typing this, my local time is:
Thu 2013-02-07 11:35:50 PST
which results in a struct tm value of (omitting some members)
(struct tm){ .tm_year = 113,
.tm_mon = 1,
.tm_mday = 7,
.tm_hour = 11,
.tm_min = 35,
.tm_sec = 50 }

You then pass (a pointer to) that struct tm into your tz_mktime()
function, which sets the time zone to UTC (by setting the
TZ environment variable to the empty string -- that's also
POSIX-specific) and then uses mktime() to convert the struct tm
value to a time_t value.

mktime() treats the above struct tm value as 2013-02-07 11:35:50 *in
local time*. Since you've set the timezone to UTC, local time is UTC.
So the result is 1360236950, the time_t representation for 2013-02-07
11:35:50 UTC -- off by 8 hours from 2013-02-07 11:35:50 PST.

> Is the lack of a TZ field in the struct tm an oversight?

I don't know if it's an oversight. <time.h> generally has poor
support for time zones.

There have been attempts to improve this (see, for example,
<http://www.cl.cam.ac.uk/~mgk25/time/c/>), but they've never actually
been incorporated into the standard.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Greg Martin <> writes:
[...]
> tzt = tz_mktime ("PST8PST", t);
[...]

Forgot to mention: that should probably be "PST8PDT".

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"