Re: [calsify] Updated JSCalendar draft version 08

[Andri Möll <[e-mail]>]

On 10/8/18 12:48 PM, Marten Gajda wrote:
>
>
> For me it would preferable to only allow a notation which contains no 
> "T" though. Allowing something like PT0H0M0S is just an additional 
> source for errors. People could come up the idea of specifying 
> PT86400S and argue that this equals 24 hours, "which is a day". After 
> all, one of the objectives of this new format is to "make it hard to 
> get it wrong."
>
> Having a format which is strict in cases like this makes it much 
> easier to argue about that.

We're talking about a dozen and a half character regular expression here 
that covers all combinations of nominal and accurate components without 
problems. What additional errors? :P

Let people specify PT86400S as an "alias" for PT24H or PT1440M. I've 
brought up three atoms in the ISO 8601 duration specification before --- 
months, days and seconds. It's very likely a duration parser internally 
decomposes those three. Whether it chooses to round to hours and minutes 
when serializing is its thing. And I doubt most distinguish between 
nominal and accurate durations at the type level anyway, thereby if all 
three atoms are zero in the input, whether the output serializes to PT0S 
or P0D is anyone's guess and shouldn't be relied on.