UTC string -> time_t

[Nick Keighley]

Hi,

this is probably quite easy...

How do I convert a UTC string into a time_t?

eg. "2007-12-18 13:37:26" -> a time_t.

Now FAQ 13.3 says use mktime() to convert a struct tm into
a time_t or you have to use some non-standard thing to parse the
string.
Assume I can parse the string and build a struct tm, how can I turn
it
into a time_t?

mktime() works on *local time* so it is going to apply the timezone
change
(the incoming string may have come from another timezone).

 

[Nick Keighley]

Hi,

this is probably quite easy...

How do I convert a UTC string into a time_t?

eg. "2007-12-18 13:37:26" -> a time_t.

Now FAQ 13.3 says use mktime() to convert a struct tm into
a time_t or you have to use some non-standard thing to parse the
string.
Assume I can parse the string and build a struct tm, how can I turn
it
into a time_t?

mktime() works on *local time* so it is going to apply the timezone
change
(the incoming string may have come from another timezone).

to save anyone the trouble of answering it looks like the way to
go is to calculate the difference between local time and UTC
by using difftime() on the results of localtime() and gmtime().
Adjusting the input value in struct tm then using mktime().

eek!

 

[Eric Sosman]

to save anyone the trouble of answering it looks like the way to
go is to calculate the difference between local time and UTC
by using difftime() on the results of localtime() and gmtime().
Adjusting the input value in struct tm then using mktime().

difftime() operates on time_t values, not on the
struct tm values produced by localtime() and mktime().
Still, you can inspect the elements of the struct tm
objects to get the offset in minutes.

The tricky part is that the difference varies with,
er, time. You can eliminate the seasonal variation (if
any) by setting the tm_isdst member to zero, but that
still leaves statutory variations unaccounted for. For
example, the Venezuela-to-UTC offset today is not the
same as it was two weeks ago. (True, the computer
systems' time services may not have caught up with the
change yet, but once they do they should give different
UTC offsets for 2007-12-08 and 2007-12-10.)

The only fully-portable approach I can think of is
to use both localtime() and gmtime() on the same time_t
value to get an initial estimate of the offset. Then
build a struct tm with the desired time, fudge it by the
estimated offset, call mktime() to get a time_t, and run
that time_t through gmtime(). If the result matches the
(un-fudged) original, you're done. Otherwise, adjust
the offset and try again.

It's a Darn Shame the standard library does not
include mkgmtime().

 

[Richard Heathfield]

Eric Sosman said:

It's a Darn Shame the standard library does not
include mkgmtime().

<shrug> I just use mktime, which does precisely the same thing as far as
I'm concerned.

 

[CBFalconer]

Eric Sosman said:



<shrug> I just use mktime, which does precisely the same thing as
far as I'm concerned.

Works for anyone. Set your system time to GMT. If you don't live
there you can add or subtract some number. It doesn't require
values larger than 13 (or 24 for the result).

 

[James Kuyper]

Works for anyone. Set your system time to GMT. If you don't live
there you can add or subtract some number. It doesn't require
values larger than 13 (or 24 for the result).

However, the method for setting the system time to GMT is
implementation-defined.

 

[Richard Heathfield]

James Kuyper said:

However, the method for setting the system time to GMT is
implementation-defined.

No, it isn't. I think you meant to say "implementation-specific" or some
such phrase. Implementations are not, for example, required to document
the method for setting the system time to GMT (which they would be
required to do if it were implementation-defined).

 

[James Kuyper]

James Kuyper said:


No, it isn't. I think you meant to say "implementation-specific" or some
such phrase. Implementations are not, for example, required to document
the method for setting the system time to GMT (which they would be
required to do if it were implementation-defined).

7.23.1p1:
"The local time zone and Daylight Saving Time are implementation-defined."

If the local time zone is settable, I don't see how the implementation
could properly define it without describing how to set it. If it's not
settable, then it's a non-issue.

 

[Richard Heathfield]

James Kuyper said:

7.23.1p1:
"The local time zone and Daylight Saving Time are
implementation-defined."

If the local time zone is settable, I don't see how the implementation
could properly define it without describing how to set it.

Borland's Turbo C conformance docs read, for the C90 equivalent of the
above: "Defined as local PC time and date."

Perfectly adequate definition, yet with no mention whatsoever of how to set
the time zone.

If it's not settable, then it's a non-issue.

I think it's a non-issue anyway.

 

[Joe Wright]

James Kuyper said:


No, it isn't. I think you meant to say "implementation-specific" or some
such phrase. Implementations are not, for example, required to document
the method for setting the system time to GMT (which they would be
required to do if it were implementation-defined).

I hope I'm not stepping in at the wrong place but..

System Time on a given system has nothing to do with a C implementation.
When you bring up a system cold you set Time in the BIOS. It is
invariably Local Time. Building a PC from parts, once you get it
running, you usually find the System Time to be Local Time in Taiwan.
You change it to Local Time where you are and go from there.

 

[user923005]

Hi,

this is probably quite easy...

How do I convert a UTC string into a time_t?

eg. "2007-12-18 13:37:26"  ->  a time_t.

Now FAQ 13.3 says use mktime() to convert a struct tm into
a time_t or you have to use some non-standard thing to parse the
string.
Assume I can parse the string and build a struct tm, how can I  turn
it
into a time_t?

mktime() works on *local time* so it is going to apply the timezone
change
(the incoming string may have come from another timezone).

I recommend:
http://www.twinsun.com/tz/tz-link.htm

The PostgreSQL code base is Berkeley licensed and has date/time
manipulation routines to do just about everything you can imagine.
All C too (no C++ or assembly).
http://www.postgresql.org/
They have a version of libtz incorporated into PostgreSQL directly,
also.

 

[Richard Heathfield]

Joe Wright said:

I hope I'm not stepping in at the wrong place but..

System Time on a given system has nothing to do with a C implementation.

Right, which is why it's not "implementation-defined", within the meaning
of the Act.