[pmwiki-users] {(...)} markup recipe available
Roman
romat2 at gmail.com
Thu Apr 12 16:17:23 CDT 2007
I like #1, #2 or #3, mostly #1.
> But ultimately the question of order for format and when comes
> down to asking which is likely to occur most often: (1) formatting
> different time values using a common default admin-defined
> format, or (2) specifying that the current time is to be displayed
> in different formats?
I can only tell you about my experience. I've already used {(ftime)}
at several places and had a need to use different time values using
same format. With default format I could be sure that all time values
(dates) will have common appearance. Format specified in {(ftime)}
would be used only if someone would intentionally want to use
different format.
In practice, I think there is a need only for two formats accross
single wiki site - one for date and another one for date & time. And
second format make sense only for 'now' and @unixtimestamp 'when'
parameters.
Roman
On 4/12/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
>
> I went with this approach because it's not obvious to me that
> omitting the format parameter will be all that common -- I can
> imagine situations where one would like to be able to specify format
> without the need to always specify the time. But there are a huge
> number of possibilities here, with no real obvious choice, so I'll
> outline a few of them and see if anyone has strong preferences.
>
> 0. We could just leave things as they are now. At the moment the
> way to specify "default format" is to put an empty format
> argument:
>
> {(ftime)} # current time in default format
> {(ftime '' '+3 hours')} # 3 hours from now in default format
>
> 1. Because the percent-sign is very unlikely to appear in a 'when'
> specification, we could say that the first argument containing
> a '%' is the format string:
>
> {(ftime %F tomorrow)} # tomorrow as yyyy-mm-dd
> {(ftime tomorrow %F)} # also works
>
> {(ftime '+3 hours')} # 3 hours from now in default format
> {(ftime %F)} # current day as yyyy-mm-dd
>
> 2. We can allow explicit "when=" and "fmt=" names on the arguments.
>
> {(ftime when=tomorrow)} # 24 hours from now in default format
> {(ftime fmt=%F)} # current day as yyyy-mm-dd
>
> 3. We could transpose the parameters (when first, format second)
> and allow an explicit fmt= to have the format go first:
>
> {(ftime tomorrow)} # 24 hours from now in default format
> {(ftime tomorrow %F)} # 24 hours from now as yyyy-mm-dd
> {(ftime fmt=%F tomorrow)} # same
>
> 4. We could keep the parameters as they are, and allow an explicit
> when= to have the when argument go first:
>
> {(ftime %F)} # current day as yyyy-mm-dd
> {(ftime %F tomorrow)} # 24 hours from now as yyyy-mm-dd
> {(ftime when=tomorrow %F)} # same
> {(ftime when=tomorrow)} # 24 hours from now in default format
>
> 5. We can have special markup expressions to indicate the
> default format parameter:
>
> {(time '+3 hours')} # time in default format
> {(isodate tomorrow)} # same as {(ftime %F tomorrow)}
> {(isotime '+3 hours')} # same as {(ftime %FT%T '+3 hours')}
>
> 6. Various combinations of the above.
>
>
> But ultimately the question of order for format and when comes
> down to asking which is likely to occur most often: (1) formatting
> different time values using a common default admin-defined
> format, or (2) specifying that the current time is to be displayed
> in different formats? I don't have a clear answer to this, so
> hearing from others would help. And if there's not a clear
> advantage to one approach over the other, then consistency says
> that we should probably use the same order of arguments that PHP's
> strftime function uses, which has the format parameter first.
>
> I think my personal preference at this point is a combination of
> #1 and #2 above, where {(ftime)} uses the first argument containing
> a percent sign as the format parameter, but the arguments can be
> made explicit by adding "when=" and/or "fmt=" to the argument.
>
> Pm
>
>
More information about the pmwiki-users
mailing list