ietf-mta-filters
[Top] [All Lists]

Re: variables: open issue a) date variables

2003-05-02 17:41:12


there are a few open issues mentioned in the draft.  I'm sure there
should be more listed, so please remind me of what I have forgotten or
glossed over.  in any case, I think it is time to try to get them
resolved.  the first one is quite trivial:

  a) should we include more predefined variables to access the time?
     (weekday, week number (US, EU and/or ISO?), name of month, name
     of weekday, ...)  could use strftime(3c) as a list of what to
     offer, but the names should be in English.

the current list is ${year} ${month} ${day} ${hour} ${minute}
${second} ${timezone}, all numeric and zero-padded.

There definitely needs to be a way to specify a day of the week. I really don't
care if it is 1/2/3/4 or mon/tue/wed or whatever, but it needs to be there
because people want to take certain actions based on the day of week.

FWIW, RFC 2445 uses

weekday    = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"

Beyond that, an iso8601 option would be useful for checking boundaries
in a single operation. RFC 3339 can be referenced for this.

I don't like adding variables with values in natural language, since
that adds internationalisation problems for little gain.
unfortunately, both weekday and week have localisation problems.

You've already bought in to the localization issue to some extent by using
Gregorian months. I think worrying about the localization issues for
days of the week is silly.

The same issue was faced in calshd. Not to put too fine a point on it, but if
users of other calendars want their weeks, months and so on represtented they
are free to write up a draft specifying such things. 

strftime(3c) solves this by supplying many conversion specifiers,
i.e. %U, %V and %W for three methods of computing the week number.  I
feel we would need to select one of these (and then the ISO
definitions is the obvious candidate), after all having one is better
than none.

Assuming we even need week number, I'd suggest %V. That's what ISO 8601
uses and what RFC 2445 picked.

for the weekday, while 0..6 with 0 meaning Sunday may seem alien to
many users (including me :), at least the information is available in
an unambigious fashion.

If you use 1/2/3 you _are_ using the Islamic days of the week ;-)

so my suggestion is to augment the list with the following:

  ${weekday}   (0..6)       %w: 0 is Sunday
  ${week}      (01..53)     %V: week number according to ISO 8601

These are both fine as far as I'm concerned.

  ${isoyear}   (0000..9999) %G: year number according to ISO 8601.
                                needed since Jan 1 2000 is in week 52
                                of 1999

The last doesn't necessarily follow. If you're using week numbers you may not
care about the specific year.

my reasoning is that this is useful information for some people, and
it is easy to implement.

Sure. Doesn't everyone have a copy of _Calendrical Calculation_ on their desk?
I certainly do.

                                Ned