mktime()
karolina
I have a strange problem. I got at tm struct that I want to convert
into seconds in a SUN solaris.
mktime() gives me different number of seconds when I trying it on
different dates even just with different times within the same date.
The only thing I want is to convert a tm struct to seconds from 1970
without manipulate with the actual date.
I got my timezone -10800 and thought that "var = mktime(&tm) -
timezone;" would give me just a conversion of my tm struct and no
manipulation.
When I have the date like example 1 mktime() return the right number
of seconds. When I have the tm struct like example 2 it return plus 1
hour which ends up to 01-JUN-2001 21:08:01 instead of 01-JUN-2001
20:08:01.
example 1.
01-JUN-2001 01:00:00
*timeptr = {
tm_sec = 0
tm_min = 0
tm_hour = 0
tm_mday = 1
tm_mon = 5
tm_year = 101
tm_wday = 0
tm_yday = 0
tm_isdst = 0
}
example 2.
01-JUN-2001 20:08:01
*timeptr = {
tm_sec = 45
tm_min = 6
tm_hour = 20
tm_mday = 1
tm_mon = 5
tm_year = 101
tm_wday = 0
tm_yday = 0
tm_isdst = 0
}
Why is this happening and what can I do about it. Is there anybody
that have som small routine or idea that or what I may use instead of
mktime().
thanks
Mark McIntyre
wrote:
>Hi,
>
>I have a strange problem. I got at tm struct that I want to convert
>into seconds in a SUN solaris.
I assume you means seconds from some epoch. Be aware that C does not
require or expect any of hte time functions to have an epoch, and even
if they do, there's no requirement for it to be the same on different
hardware.
>mktime() gives me different number of seconds when I trying it on
>different dates even just with different times within the same date.
Not sure what you mean - different dates are naturally different
numbers of seconds from your epoch.
>The only thing I want is to convert a tm struct to seconds from 1970
>without manipulate with the actual date.
How about using difftime()?
>I got my timezone -10800 and thought that "var = mktime(&tm) -
>timezone;" would give me just a conversion of my tm struct and no
>manipulation.
That is meaningless. Whats with 10800? mktime returns a time_t, which
is arithmetic, not necessarily integer. You're relying on Sun-specific
stuff here...
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Gordon Burditt
>into seconds in a SUN solaris.
>mktime() gives me different number of seconds when I trying it on
>different dates even just with different times within the same date.
Why wouldn't you expect that? Seconds tick by during the day
as well as when the calendar rolls over to another day.
>The only thing I want is to convert a tm struct to seconds from 1970
>without manipulate with the actual date.
ANSI C does not give any guarantee that a time_t represents a
number of <unit of time> since <event>, much less any mention of
1970 or seconds. "number of beers since my birth" is distinctly
non-linear as most people don't have many beers by age 10.
What does "without manipulate with the actual date" mean? Is
it a subject for alt.sex.erotica.dates.hand ?
>I got my timezone -10800 and thought that "var = mktime(&tm) -
>timezone;" would give me just a conversion of my tm struct and no
>manipulation.
Subtracting an integer from a time_t is not guaranteed to give
you much besides undefined behavior.
>When I have the date like example 1 mktime() return the right number
>of seconds. When I have the tm struct like example 2 it return plus 1
>hour which ends up to 01-JUN-2001 21:08:01 instead of 01-JUN-2001
>20:08:01.
>
>example 1.
>01-JUN-2001 01:00:00
>*timeptr = {
> tm_sec = 0
> tm_min = 0
> tm_hour = 0
> tm_mday = 1
> tm_mon = 5
> tm_year = 101
> tm_wday = 0
> tm_yday = 0
> tm_isdst = 0
>}
>
>example 2.
>01-JUN-2001 20:08:01
>*timeptr = {
> tm_sec = 45
> tm_min = 6
> tm_hour = 20
Um, for 8 minutes past the hour, you have tm_min = 6? Huh?
For one second past the minute you have tm_sec = 45?
> tm_mday = 1
> tm_mon = 5
> tm_year = 101
> tm_wday = 0
> tm_yday = 0
> tm_isdst = 0
I note you set tm_isdst = 0? Is Daylight Savings time not in
effect ever where you live?
>}
>
>Why is this happening and what can I do about it. Is there anybody
>that have som small routine or idea that or what I may use instead of
>mktime().
Since you don't give any actual examples of what mktime() returns
for given input, it's hard to check it.
Gordon L. Burditt
Richard Heathfield
>
> >mktime() gives me different number of seconds when I trying it on
> >different dates even just with different times within the same date.
>
> Not sure what you mean - different dates are naturally different
> numbers of seconds from your epoch.
Note that mktime() yields a time_t, *not* (necessarily) a number of
seconds.
If you need to know the number of seconds between the times represented
by two time_t objects, use difftime().
> >The only thing I want is to convert a tm struct to seconds from 1970
> >without manipulate with the actual date.
>
> How about using difftime()?
Quite so. :-)
>
> >I got my timezone -10800 and thought that "var = mktime(&tm) -
> >timezone;" would give me just a conversion of my tm struct and no
> >manipulation.
>
> That is meaningless. Whats with 10800? mktime returns a time_t, which
> is arithmetic, not necessarily integer. You're relying on Sun-specific
> stuff here...
He certainly is. He may (or may not) find out that everything magically
resolves itself if he correctly initialises his struct tm before using
it. *All* the fields must have determinate values, not just the ones he
thinks are important - otherwise it's pretty likely to return an error
condition.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
karolina
> >I have a strange problem. I got at tm struct that I want to convert
> >into seconds in a SUN solaris.
>
> >mktime() gives me different number of seconds when I trying it on
> >different dates even just with different times within the same date.
>
> Why wouldn't you expect that? Seconds tick by during the day
> as well as when the calendar rolls over to another day.
Okey, what I mean is that when I run my date as example 1 into mktime
I also get 01-JUN-2001 01:00:00 expressed in seconds as output which
is what i put in. When I run example 2 though the same testprogram I
get 01-JUN-2001 21:08:01 which is one hour offset from my date that I
ran through the mktime.
> >The only thing I want is to convert a tm struct to seconds from 1970
> >without manipulate with the actual date.
>
> ANSI C does not give any guarantee that a time_t represents a
> number of <unit of time> since <event>, much less any mention of
> 1970 or seconds. "number of beers since my birth" is distinctly
> non-linear as most people don't have many beers by age 10.
Hmmm, this was new to me. Do I understand you correct if the out value
from mktime doesn't give me the exact seconds from 19700101 UTC to the
UTC time of the date that was my input tm-struct to mktime()?
If it doesn't, what does it give me and what use may I have of the
return value from mktime?
Where is this described?
This is what man say:
"The mktime() function converts the time represented by the tm
structure pointed to by timeptr into a calendar time (the number of
seconds since 00:00:00 UTC, January 1, 1970)."
> What does "without manipulate with the actual date" mean? Is
> it a subject for alt.sex.erotica.dates.hand ?
I just want a routine that takes a date on a tm structure and convert
it into seconds from 19700101. What I mean is that if I run
04-JUN-1987 21:00:00 through the routine it gives me the number of
seconds from 01-JAN-1970 00:00:00 -> 04-JUN-1987 21:00:00. I do just
want to convert this into seconds and do not take care of what offset
from UTC or dts I got at the moment.
> >I got my timezone -10800 and thought that "var = mktime(&tm) -
> >timezone;" would give me just a conversion of my tm struct and no
> >manipulation.
>
> Subtracting an integer from a time_t is not guaranteed to give
> you much besides undefined behavior.
I guess this doesn't work since I thought that mktime gave me seconds
from 19700101, or?
timezone is not an integer it's a time_t
timezone = mktime(&unix_zero_date) where unix_zero_date is 19700101
just to get the UTC offset
> >When I have the date like example 1 mktime() return the right number
> >of seconds. When I have the tm struct like example 2 it return plus 1
> >hour which ends up to 01-JUN-2001 21:08:01 instead of 01-JUN-2001
> >20:08:01.
> >
> >example 1.
> >01-JUN-2001 01:00:00
> >*timeptr = {
> > tm_sec = 0
> > tm_min = 0
> > tm_hour = 0
> > tm_mday = 1
> > tm_mon = 5
> > tm_year = 101
> > tm_wday = 0
> > tm_yday = 0
> > tm_isdst = 0
> >}
> >
> >example 2.
> >01-JUN-2001 20:08:01
> >*timeptr = {
> > tm_sec = 45
> > tm_min = 6
> > tm_hour = 20
>
> Um, for 8 minutes past the hour, you have tm_min = 6? Huh?
> For one second past the minute you have tm_sec = 45?
Yes, I cut 'n pasted this and got the wrong tm structure, sorry
> > tm_mday = 1
> > tm_mon = 5
> > tm_year = 101
> > tm_wday = 0
> > tm_yday = 0
> > tm_isdst = 0
>
> I note you set tm_isdst = 0? Is Daylight Savings time not in
> effect ever where you live?
I just want to convert the tm struct to seconds no matter what the
Daylight Saving time is at the moment.
> >}
> >
> >Why is this happening and what can I do about it. Is there anybody
> >that have som small routine or idea that or what I may use instead of
> >mktime().
>
> Since you don't give any actual examples of what mktime() returns
> for given input, it's hard to check it.
> Gordon L. Burditt
Thank you!
Gordon Burditt
>> >different dates even just with different times within the same date.
>>
>> Why wouldn't you expect that? Seconds tick by during the day
>> as well as when the calendar rolls over to another day.
>
>Okey, what I mean is that when I run my date as example 1 into mktime
>I also get 01-JUN-2001 01:00:00 expressed in seconds as output which
>is what i put in. When I run example 2 though the same testprogram I
>get 01-JUN-2001 21:08:01 which is one hour offset from my date that I
>ran through the mktime.
You might consider initializing *ALL* the fields of struct tm.
>> >The only thing I want is to convert a tm struct to seconds from 1970
>> >without manipulate with the actual date.
>>
>> ANSI C does not give any guarantee that a time_t represents a
>> number of <unit of time> since <event>, much less any mention of
>> 1970 or seconds. "number of beers since my birth" is distinctly
>> non-linear as most people don't have many beers by age 10.
>
>Hmmm, this was new to me. Do I understand you correct if the out value
>from mktime doesn't give me the exact seconds from 19700101 UTC to the
>UTC time of the date that was my input tm-struct to mktime()?
No. It gives you a time_t. ANSI C says nothing whatever about
how a time_t is represented.
A perfectly legal representation of a time_t (but a bit wasteful in
bits) would be to form the decimal number HHMMSSYYYYYmmDD, where:
HH = hour (0-23)
MM = minutes (0-59)
SS = seconds (0-60 - leap seconds!)
YYYYY = year (1 - 99999, warning: Y100K bug! I don't want to get into
arguments about the existence of year 0.)
mm = month (1-12 - yes, I know struct tm doesn't represent it this way)
DD = day (1-31)
Now interpret it as one big decimal number (probably won't fit in 32 bits,
maybe will barely fit in an unsigned 48 bit integer)
Note the properties of this representation:
- Any time in the afternoon is MUCH larger than any time in the morning,
even if it's centuries earlier.
- Subtracting two time_t's provides no useful clue as to how far apart
the times are or even which one comes earlier. difftime() on this
implementation would be a non-trivial function.
>If it doesn't, what does it give me and what use may I have of the
>return value from mktime?
The return value from mktime is a time_t. If you want to do direct math on it,
tough noogies, there are no guarantees that it will work. difftime()
is provided, though. And you can feed it to localtime() to get the
struct tm back.
>Where is this described?
The ANSI C standard describes the guarantees you have about a time_t
(which are darn few). NOWHERE is there a description of the
guarantees you thought you had but don't.
>This is what man say:
>"The mktime() function converts the time represented by the tm
>structure pointed to by timeptr into a calendar time
OK so far.
(the number of
>seconds since 00:00:00 UTC, January 1, 1970)."
This is completely system-dependent.
>> What does "without manipulate with the actual date" mean? Is
>> it a subject for alt.sex.erotica.dates.hand ?
>I just want a routine that takes a date on a tm structure and convert
>it into seconds from 19700101. What I mean is that if I run
>04-JUN-1987 21:00:00 through the routine it gives me the number of
>seconds from 01-JAN-1970 00:00:00 -> 04-JUN-1987 21:00:00. I do just
>want to convert this into seconds and do not take care of what offset
>from UTC or dts I got at the moment.
It's not meaningful to make such calculations without time zone
information. The 01-Jan-1970 00:00:00 of POSIX fame is in *UTC*,
but the date you are feeding it is in your local time zone. Time
zone information (including daylight savings time) is needed for
the calculation.
>> >I got my timezone -10800 and thought that "var = mktime(&tm) -
>> >timezone;" would give me just a conversion of my tm struct and no
>> >manipulation.
>>
>> Subtracting an integer from a time_t is not guaranteed to give
>> you much besides undefined behavior.
>
>I guess this doesn't work since I thought that mktime gave me seconds
>from 19700101, or?
>timezone is not an integer it's a time_t
>timezone = mktime(&unix_zero_date) where unix_zero_date is 19700101
>just to get the UTC offset
You can do something like this:
#include <time.h>
...
time_t epoch, now;
struct tm unix_zero_date;
struct tm now_tm;
unsigned long seconds_since_epoch;
...
/* initialize unix_zero_date and now_tm here */
epoch = mktime(&unix_zero_date);
now = mktime(&now_tm);
seconds_since_epoch = difftime(epoch, now);
This works assuming that unix_zero_date and now represent times within
the range of a time_t. Since some Microsoft-based systems use a time
based on Jan 1, 19*8*0, this assumption is not always valid.
I just want to convert 50 coins to a specific number of U.S. Dollars,
regardless of whether they are quarters or pennies. Unfortunately, banks
won't go along with that idea.
>
>> >}
>> >
>> >Why is this happening and what can I do about it. Is there anybody
>> >that have som small routine or idea that or what I may use instead of
>> >mktime().
>>
>> Since you don't give any actual examples of what mktime() returns
>> for given input, it's hard to check it.
>> Gordon L. Burditt
>
>Thank you!
Gordon L. Burditt
Villy Kruse
Gordon Burditt <gordon...@sneaky.lerctr.org> wrote:
>>>
>>> I note you set tm_isdst = 0? Is Daylight Savings time not in
>>> effect ever where you live?
>>
>>I just want to convert the tm struct to seconds no matter what the
>>Daylight Saving time is at the moment.
>
>I just want to convert 50 coins to a specific number of U.S. Dollars,
>regardless of whether they are quarters or pennies. Unfortunately, banks
>won't go along with that idea.
>
Set tm_isdst = -1 if you wan't the system to figure out whether the
time is daylight saving time or not. Otherwise you tell mktime wheter
you specified a daylight saving time or standard time.
Villy