According to mike grommet:
> I am going through and printing out the individual values of new_time:
>
> time: 2001-04-05 - this is from your original code
> hour: 1 - why 1? doesnt really matter tho
> min: 0 - checks fine here
> sec: 134799364 - WOW! thats a lot of seconds.
> month: 3 - this one is right
> day: 5 - here too
> year: 101 - just fine here
> othertime: 1121145364 ---- translates to sometime in July 2005 I think
>
> Ok, well the seconds info just screams out at me so I've hacked the code
> abit to initialize new_time... here is my final routine (so far) with my
> debug code too:
> void
> Retriever::got_time(char *time)
> {
> time_t new_time;
> struct tm tm;
Yes, as you've figured out, when you declare a structure like this in
a function, it's just allocated on top of existing memory, without any
sort of initialisation or zeroing out. For all intents and purposes,
you can consider its contents to be random. You must explicitly
initialise the structure members...
> // added by me
> tm.tm_hour = 0;
> tm.tm_min = 0;
> tm.tm_sec = 0;
> tm.tm_mon = 0;
> tm.tm_mday = 1;
> tm.tm_year = 0;
>
> if (debug > 1)
> cout << "\ntime: " << time << endl;
>
> //
> // As defined by the Dublin Core, this should be YYYY-MM-DD
> // In the future, we'll need to deal with the scheme portion
> // in case someone picks a different format.
> //
strptime() just sets the fields that are specified in the format string,
so all other fields in the structure ought to be initialised explicitly
by you.
> if (mystrptime(time, "%Y-%m-%d", &tm))
> {
> if (debug > 1)
> {
> cout << "\nhour: " << tm.tm_hour << endl;
> cout << "\nmin: " << tm.tm_min << endl;
> cout << "\nsec: " << tm.tm_sec << endl;
> cout << "\nmonth: " << tm.tm_mon << endl;
> cout << "\nday: " << tm.tm_mday << endl;
> cout << "\nyear: " << tm.tm_year << endl;
> }
> //#if HAVE_TIMEGM
> new_time = timegm(&tm);
> //#else
> // new_time = mytimegm(&tm);
> //#endif
> current_time = new_time;
> if (debug > 1)
> cout << "\nothertime: " << current_time << endl;
> }
>
> // If we can't convert it, current_time stays the same and we get
> // the default--the date returned by the server...
> }
..
> Note, in my code above, I have disabled the mytimegm. Strangely enough,
> timegm and mytimegm do NOT
> return the same values, they are exactly 24 hours off from one another.
Yes, as I reported back in February, mytimegm() doesn't correctly recognise
2000 as a leap year, so any date given to it on or after Mar. 1, 2000, will
be off by one day. I posted a patch when I found the bug (I can resend it
if you want, but it should be in the archives). This is fixed for future
releases.
> Which brings me to my second and more minor problem:
> when the list of results are displayed, instead of treating the time as UTC,
> as the rest of
> my code for search ranges does already, it seems that
> the code for outputting date information on search results:
..
> is using localtime instead. Just wondering if should be default or not...
> its definately a problem with
> my particular implementation, since date ranges are searched by using UTC
> time, so the date appears
> short by one day. If you think I should change my current search routines so
> that time zones are taken
> into account, I can probably do that, but I'm not sure exactly where to
> begin.
>
> What do you think?
As I said before, back-end (i.e. server interface) must be UTC, but
front-end (i.e. user interface) can be what you want. Server's local time
seems to make the most sense. In any case, you should use the local time
zone for your date ranges if you're keeping the dates displayed in local
time, as they are now. I believe that if you use mktime() instead of
timegm() or mytimegm() to convert your start & end of range tm structures
to time_t, it will convert from the local time zone. Give it a try.
The rest of Geoff's patch looks fine to me. Just the tm structure
initialisation was missing.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
