[pmwiki-users] Conditional Directive based on time - standards

[Neil Herber]

My comments interspersed below ...

At 2005-10-13  10:04 AM -0500, Patrick R. Michaud is rumored to have said:
>AFAIK, both of the existing calendar recipes (PmCal and WikiCalendar)
>produces page names in the form yyyymmdd, so I think we ought to
>stick with that format, or at least make sure it's allowed.  In
>particular, it might be nice to be able to write something like
>
>     (:if date {$Name}:) Today's events: (:if:)
>
>so that "Today's events" only displays on the page corresponding to
>the current date.
>
>However, I don't have a problem with setting the date code to
>ignore non-digit characters altogether, so that one can write any
>of 20051014, 2005-10-14, 2005/10/14, or 2005.10.14 and have things
>work out correctly.

For all the obvious benefits, I use ISO-formatted dates whenever 
possible. To conserve space I use 20051013. To make things more 
readable, I use 2005-10-13. If either or both worked, that would be great.

At the risk of creeping featuritis, perhaps there could be a 
(:datespaced:) directive that could convert 20051013 to 2005-10-13 
for display. Not sure how to distinguish between dates and other sets 
of numbers ....

>To be consistent with the (:include:) markup, I'm also thinking that
>we should specify ranges with "..", thus
>
>     (:if date 20051014..20051020:)    Oct 14 through Oct 20
>     (:if date 20051014..:)            On or after Oct 14
>     (:if date ..20051020:)            On or before Oct 20

These are excellent - compact, easy to read, and unambiguous.

>I'm not yet a big fan of the "before", "after", "future", "past",
>"between", etc. keywords--I don't think they're obvious on their
>face and still require explanation.  (We can always add keyword-based
>times later if we decide we need them.)

In English, time related keywords are horribly ambiguous. I would 
ignore them for a long time.

>I like offset dates--i.e.,  "+30days", "+2months", "+1year",
>but they may be left for the second iteration of the code.
>The interpretation of something like "20051005..+10days"
>should probably be "ten days starting with Oct 5", thus "Oct 5
>through Oct 14".

Offsets just seem to reintroduce ambiguity. If an event starts on 
20051013 and runs for 5 days do I type "20051013..+5days"? My brain 
tells me that that should be the same as "20051013..20051018" (13 
plus 5 equals 18), but what I really want is "20051013..20051017".

>I doubt we'll have "today", "tomorrow", etc. substitutions for
>a while -- they may just cause too much confusion.

Agreed.

>I'm still on the fence about truncated dates and allowing time
>specifiers.  It's not an implementation problem, but enough people
>have said that they'd like dates-always-in-one-format that
>I'm reluctant to include the extended forms by default.  Perhaps it
>will be an option for the wikiadmin, or maybe a different (:if:)
>condition name that says the extra date/time formats are okay.
>
>     (:if date_t 200510..2006:)         # 2005-Oct-01 through 2006-Dec-31
>     (:if date_t ..2005-10-13T12:00 :)   # until noon on 2005-Oct-13

I would vote for a single date-only format to start with time added 
as a local option (if demand exists). For local wikis, time may be 
useful, but for geographically dispersed wikis things start to get 
complicated. The dates and times are relative to the server clock, 
not to the location of the reader.

Several of my wikis have users in Eastern North America  and Europe, 
but the time difference is small enough (6 hours) that it is 
generally the same day for all users during daylight hours.


Neil

Neil Herber
Corporate info at http://www.eton.ca/
Eton Systems, 15 Pinepoint Drive, Nepean, ON, Canada K2H 6B1
Tel: (613) 829-4668