I also don't see this as a core feature. I would also not render relative timestamps on server side, but rather let this to be done on client side to improve caching. Something like this:
<span data-timestamp="<%= time %>" class="timestamp><%= pretty_absolute_time %></span> Doing it on the client side also has advantages by allowing the "less than a minute ago" string to be changed as time goes along in the browser. On Thursday, August 28, 2014 7:37:21 AM UTC+2, Justin Hawkins wrote: > > > On 28 Aug 2014, at 1:25 pm, sri <[email protected]> wrote: > > > A few words about the motivation. Like many Perl hackers, since the > closure of Google Groups i'm a regular visitor of the Planet Perl Iron Man > site (http://ironman.enlightenedperl.org/), which is a very good example > for something quickly hacked together and never cleaned up. You don't even > have to look at the code, which still sports the stub documentation > generated by Catalyst. One of the first thing that jumped into my eye were > those horrible timestamps, even for a quick hack you should never have to > choose those. Mojolicious needs to be better than that, making > aesthetically pleasing applications has to be easy by default. > > I share this pet peeve. I’ve been using Time::Duration since … forever. > > Mojo::Date has a nicer interface, but I still don’t know how I feel about > it being in core. > > I can see the arguments for - date and time handling comes up in almost > any non-trivial web app, and you might as well make it look good and make > sense. > > Overall I think I’m in favour. Not sure about the ‘cutesy dates’ name :-) > > - Justin -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
