add a setting to format timestamps and Dates+discussion
*edit help should link to simple documentation on this sort of thing
%A, %B %d, %Y %I:%M %p %Z
Does this apply only to things like *when created? Or also to dates? (Do dates currently even store the time?)
dates are currently just dates, but it should still apply. http://www.dzone.com/snippets/date-time-format-ruby
This is an old ticket. does it literally mean a setting? seems a bit half baked...
If you want to be able to use different formats in different contexts then setting seems just right, no? "blog entry+*date edited+*type plus right+*date format" for blog entries, "User+birthday+*type plus right+*date format" for user birthdays, etc.
It does seem a bit half-backed, but in general I like the idea.
Needs more baking, though. I think we need to represent date/times/datetimes as the same thing in the core code, and following AWAP put a lot of the work into 1) Good handling via defaults and editors, and 2) Wagneerable selection of variations. I would want to follow DB practice of storing datetime values as numbers (inherited from ruby for Wagn).
Can I (a) acknowledge that calling something "half-baked" without spelling out the deficiencies can be pretty annoying, and (b) NOT commit to eradicating the practice? :)
I'll try to spell out some of the questions above.
The general issue of when something should be a setting probably needs more attention. My current tendency is towards conservatism there, but that may shift, particularly as we get better interface for preventing settings overwhelm. Still, at present I can see *comment and *accountable disappearing into trait handling while *send and *thanks disappear into event triggers. So we may be trimming!
I wish we could have a space that was a bit more experimental than "released Wagns" for playing seriously with variation. I totally understand being conservitive WRT released product, and I also want the benefits of agile release of partly backed ideas in the development space. Right now we don't have the numbers of coder eyeballs to justify it, but we want to think about this for the future.
also see add configuration of site time zone