> ...
>> Umm, did you see any indication that they intend to allow "-" /anywhere/
>> in a time interval (with the exception of between year and month, month
>> and day in the alternate form, as simple delimiters, not as minus?
>> (Maybe you did; I'm looking at a publicly-accessible 2016 draft.)
>
> I don't have an "official" copy either; I was looking at this draft:
> https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf
heh, no one has an up to date standard :-) Also that is the link I meant
to include in my first reply. From what I see at
https://www.iso.org/obp/ui/#iso:std:iso:8601:-2:ed-1:v1:en they (ISO) did
address negative values for components and also there is "3.1.1.7
negative duration" that would be nice to read somehow.
> I see this bit:
>
> [±] represents a plus sign [+] if in combination with the following
> element a positive value or zero needs to be represented (in this
> case, unless explicitly stated otherwise, the plus sign shall not be
> omitted), or a minus sign [−] if in combination with the following
> element a negative value needs to be represented.
But nowhere near duration specification [±] is used whatsoever.
> Hm. The slippery slope I *don't* want to be drawn down is somebody
> arguing that we should change interval_out, because that would open
> a whole Pandora's box of compatibility issues. Maybe we should just
> take the position that negative intervals aren't standardized, and
> if you want to transport them using ISO format then you first need
> to lobby ISO to fix that.
I explicitly do NOT want to change anything on the way out. First, that
is how things are and we do not want to break anything. And, second, in
many cases client software can read either format. That is why I thought
it would be a trivial change. No output changes.
--
Mikhail
