add a setting to format timestamps and Dates+ticket line view
On a low level, we probably want to make use of ruby's "strftime", which offers a lot of flexibility, and can be done securely because it's just a string (not executable code). Below is an example of strftime in use for the *now card:
define_view :raw, :name=>'now' do |args|
Time.now.strftime('%A, %B %d, %Y %I:%M %p %Z')
end
The string in bold is what we want to allow wagneers to configure. We could eventually build clean interface for choosing / constructing such strings.
Much less clear is what's needed on a high level. One idea proposed has been that there be a setting like "*time format". There are several problems that would have to be worked out for that to fly:
- We generally want the format to be determined by the context, not the date. Consider the *now card; you might sometimes want to show it in words, other times in numbers. If our only tool is a rule on the *now card, then how does that work?
- Similarly, let's say there's a card "my schedule" with 20 dates on it. You often want them all formatted the same way. How's that work? One obvious proposal is that there is a format rule on "my schedule", but then we have an interesting question of where we find the rule. If "my plan" includes "my schedule" includes "my appointment" includes "my appointment+time", where do we go to find our rule? Remember, if there's a *all rule, they all have one, so you'd have to have some principle that would allow you NOT to use that rule on "my appointment+time" in order to know how to contextualize it.
- this gets even messier when you consider that you typically need separate handing for dates, times, and combinations thereof. Do we create settings for each?
My impulse is to say that this may make more sense to handle in inclusion syntax, but that idea will need baking, too.
dates, times, and combinations thereof needed to be formatted differently in different contexts. that needs to be wagneerable.
*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