I just checked in (r548) the date-formatting code I've been tinkering
with - on the surface, it adds to the existing normalize_time API -- it
which used to be:
normalize_time(t)
which formatted the given datetime as a time only.
Now, it's:
normalize_time(start_time, end_time, opts)
and formats the times _and dates_ without redundant information, based
on the options given:
- With :format => :hcal, the default, it'll return the date range
formatted for inclusion in an hCalendar block (I've added whitespace for
readability here):
<abbr class=\"dtstart\" title=\"2008-04-01T09:00:00\">
Tuesday, April 1, 2008 from 9am
</abbr>
–
<abbr class=\"dtend\" title=\"2008-04-01T13:30:00\">
1:30pm
</abbr>
- With :format => :html, it leaves off the hCalendar tags:
Tuesday, April 1, 2008 from 9am–1:30pm
- With :format => :text, no entity for the dash:
Tuesday, April 1, 2008 from 9am-1:30pm
- With :context => some_date, it leaves off information that's provided
by that date: it removes the year from either end of the time range that
happens to be the current year, so after Christmas you might see:
Tuesday, December 30 at 3pm through Friday, January 2, 2009 at 8pm
- Also with :context => some_date, it leaves off all of the date stuff
and just formats the times, if the date given is the same as both ends
of the range:
9-4pm
- A multiday event from the context date to a different date would show:
9am through Wednesday, April 17
- It uses words like "noon" and "midnight". (It can be called with a
":relative => true" option, to use words like "yesterday", "today", and
"tomorrow", but at the moment it seems appropriate only to use those
words in the labels on the front page, which aren't produced using this
code. [I'm using this code in another project where this feature is
useful.])
- Instead of start_time and end_time, you can pass an object that
responds to start_time and maybe end_time... like one of our Events.
FYI: when drawing events on the front page, we pass the event's start
date as the context date - this effectively suppresses the start date
info for all the events, which makes sense if you think about it:
they're already labeled with their start dates. Have a look at the
current front page - it has lots of realistic use cases :-).
The code to do this turned out more complicated than I'd like. If anyone
would like to sit down and review it with me and suggest alternative
approaches, I'd appreciate it.
...Bryan
...Bryan
Bill Burcham wrote:
> Have you considered using the chronic gem
> <http://chronic.rubyforge.org/> to support this sort of interpretation?
> >
Reid