Marc Dirix <[email protected]> wrote: > Currently the emit timerange tag sets the to-date/year/time, if not > given to the time of the from-date/year/time. > > Wouldn't it be more convenient if the to-date/year/time, if not given as > an argument, is set to the "current" time?
I don't really know, but that wouldn't be compatible in any case. What could be added is the possibility to specify a special value "now" for the current time. Maybe there already is something like that - I haven't checked. > &_.month; returns the month-number e.g. "01" for January. > Whereas &_.next_month; returns the month-name + month-number e.g. > "January 01" for January. > > &_.next.year; does the same, returning "December 2012" (where &_.year; > returns "2011"). Although this is understable, because my unit="months" > so it returns the same month next year, I think it is a bit counter > intuitive, because joining _.month + _.next.year would give the same > result, whereas if I just want the number of next.year, I'd have to > sscanf it (or add 1 tot _.year, manually). I agree, both sound like messy special cases. I wonder if they're intentional. Anyway, these too are probably not possible to change without compat issues - if you're writing code to sscanf out the parts you want, then it's likely there's other code like that out there, and it would start to fail. In these cases it's maybe possible to change for a future version, so that the old behavior is retained with the compat level setting. But I'm not familiar enough with the typical use of those emit#timerange features. Maybe this quirky behavior often is convenient somehow?
