Geoff Hutchison (firstname.lastname@example.org)
Tue, 30 Mar 1999 13:55:42 -0500 (EST)
On Tue, 30 Mar 1999, mike grommet wrote:
> I feel tho that the sorting on date capability is needed, in many cases.
> (not to mention, in my current project <g>)
I think you meant "searching on date capability..." Sorting was nicely
contributed by Gilles Detillieux fopr 3.1.0. ;-)
> No one is indexing on the fly anyway right? So I assume we could just zero
> out the
> hrs, mins, second fields of the date+time?
At the moment I cannot see why someone would want to search for an exact
time. However, assumptions about not indexing on the fly should not be
made since that's one of the goals for 3.2.
To answer your question, for now you can just zero out the hr, min, sec.
fields (which will set it to midnight). Life gets a bit more complicated
since we still have to figure out what timezone... For simplicity, I
suggest the *server's* timezone (which may not be the same as the
> I would expect the entering of dates
> using month, day, year select boxes (1 each). Then, htsearch can piece them
> together into one long string
> for the comparison?
Well there seems to be consensus for separate fields for from-month,
to-month, etc. This would solve the formatting problems--they're
unambiguous. And people could write wrappers to convert their format to
the expected multiple-field format. Sounds fine with me.
(BTW, it should probably be written that if a field is missing, it's reset
to the minimum. So from-year=1999 goes from 1/1/99... Also, if the
to fields are missing, they should probably be set to the current time by
> Also, we definately need to consider the possibility of the user
> entering in an invalid date, such as Feb 30, and such.
Acutally, this should be handled nicely by the system routines. For
example, we're not going to get a time_t value, so we might as well just
send it to mktime. It will deal with incorrect dates for us.
Williams Students Online
To unsubscribe from the htdig mailing list, send a message to
email@example.com containing the single word "unsubscribe" in
the SUBJECT of the message.
This archive was generated by hypermail 2.0b3 on Tue Mar 30 1999 - 13:26:18 PST