Afficher un message
Vieux 07/04/2008, 20h10   #4
Victor Bazarov
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: gmtime_r or strftime problem or just my code?????

eskgwin@gmail.com wrote:
> On Apr 7, 10:51 am, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
>> eskg...@gmail.com wrote:
>>> I have this piece of code that takes a day of the year and converts
>>> it to the month and day of month:

>>
>>> char start_mon[40];
>>> char start_day[40];
>>> int s_day = 84;
>>> time_t daysecs = (s_day * 86400) - 1;
>>> struct tm tm_result;


What is this for?

>>> struct tm *tm_time = &tm_result;


Why do you need to initialise 'tm_time' just to lose the value and get
a new one in the next statement?

>>> tm_time = gmtime_r(&daysecs,&tm_result);

>>
>>> strftime(start_mon, sizeof(start_mon), (char*)"%m", tm_time);
>>> strftime(start_day, sizeof(start_day), (char*)"%d", tm_time);

>>
>>> I am just testing it with 84, but this is a parameter to the method.
>>> Anyway, the month and day should be 03 24, but I am getting 03 25.


Have you tried subtracting more than 1 when calculating 'daysecs'?
Put it in a loop and see when you get a different value. Just curiuos
because it seems that day 0 would actually mean that 'daysecs' is -1,
which doesn't seem right.

>>> It seems like it is not taking into account leap year. Is it
>>> gmtime_r or strftime or something else? Do I need to actually check
>>> the year and figure out if it is a leap year? I was hoping there
>>> was something that would do that automatically, but probably not.
>>> Thanks.

>>
>> What's "gmtime_r"?
>>
>> V
>> --
>> Please remove capital 'A's when replying by e-mail
>> I do not respond to top-posted replies, please don't ask- Hide
>> quoted text -
>>
>> - Show quoted text -

>
>
> gmtime_r() -- Convert Time (Restartable)
> [..]


So, it's exacly like 'gmtime', only the standard function does not
define 'time_t' type as the number of seconds since some date. There
is no requirement that 'time_t' is implemented in seconds.

>
> Calendar time is the number of seconds that have elapsed since EPOCH,
> which is 00:00:00, January 1, 1970 Universal Coordinate Time (UTC).


Well, this is apparently the definition on *your* system, it is not
the general definition, just so that you know...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


  Réponse avec citation
 
Page generated in 0,06736 seconds with 9 queries