add a setting to format timestamps and Dates


add a setting to format timestamps and Dates+status
add a setting to format timestamps and Dates+priority
add a setting to format timestamps and Dates+tag
add a setting to format timestamps and Dates+commit

add a setting to format timestamps and Dates+issues

dates, times, and combinations thereof needed to be formatted differently in different contexts.  that needs to be wagneerable.


add a setting to format timestamps and Dates+solution

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|'%A, %B %d, %Y %I:%M %p %Z')


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:

  1. 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?
  2. 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.
  3. 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.



*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 Date? (Do dates currently even store the time?)

--John Abbe.....2013-05-07 23:14:14 +0000

dates are currently just dates, but it should still apply.


This is an old ticket. does it literally mean a setting? seems a bit half baked...

--Ethan McCutchen.....2013-05-08 03:56:17 +0000

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.

--John Abbe.....2013-05-08 12:52:48 +0000

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).

--Gerry Gleason.....2013-05-08 13:23:12 +0000

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.

--Ethan McCutchen.....2013-05-08 15:17:51 +0000

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!

--Ethan McCutchen.....2013-05-08 16:08:54 +0000

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.

--Gerry Gleason.....2013-05-08 19:21:10 +0000

also see add configuration of site time zone

--John Abbe.....2013-05-08 22:38:41 +0000