Support ISO 8601

[rebolbot]

Submitted by: Ladislav

I want LOAD to be able to "understand" the examples below, and I want MOLD/ALL (maybe even MOLD) to produce them.

Advantages:

• no "clash" with path syntax (see Path! syntax and date! syntax clash #2089)
• support for ISO 8601

Disadvantages:

• do not think there are any

2013-11-08T17:01
2013-11-08T17:01+01
2013-11-08T17:01Z

^{CC - Data [ Version: r3 master Type: Wish Platform: All Category: Syntax Reproduce: Always Fixed-in:none ]}

[rebolbot]

Submitted by: abolka

I'd also like to see this supported (including formats with seconds and fractional seconds).

[rebolbot]

Submitted by: Gregg

+1 for loading them.

-1 for MOLD creating them.

-0.5 for MOLD/ALL creating them.

One concern is what level of ISO8601 compatibility is implied/supported. I use my own FORMAT and loaders funcs to create and parse them today, which makes it clear.

[rebolbot]

Submitted by: maxim

+1 For me, I don't like the molded notation right now, its not international.

I'd prefer ISO format, it would be much simpler for web and xml manipulation tools.

[rebolbot]

Submitted by: rgchris

I am for this, or at least using RFC3339 as the default representation of time.

http://www.ietf.org/rfc/rfc3339.txt

[rebolbot]

Submitted by: BrianH

Don't support the more obscure formats of ISO8601, just the common, recommended formats that don't conflict with our other datatypes. Hyphens required in dates, colons required in times, no non-numeric time zones except the Z for UTC thing, no 2-digit years, no week dates or ordinal dates, and nothing from the standard that we don't support in the semantics of our date! or time! types. Only support negative years if our semantic model allows them.

We should also make sure TO-DATE allows the variant where a space is used instead of a T, and no Z is included, to be able to handle the most common variant. We wouldn't be able to or need to support that variant in normal LOAD syntax though. We might want TO-DATE to support some of the other semantics-compatible ISO8601 syntaxes, like skipping the hyphens for instance, but we'll see if it's worth it.

[rebolbot]

Submitted by: BrianH

This is a dup of #438.

[Oldes]

Red language is able to load iso8601 dates as provided in Ladislav's request:

>> 2013-11-08T17:01
== 8-Nov-2013/17:01:00
>> 2013-11-08T17:01+01
== 8-Nov-2013/17:01:00+01:00
>> 2013-11-08T17:01Z
== 8-Nov-2013/17:01:00

So it would be nice to have it in Rebol too.

[hostilefork]

no "clash" with path syntax (see #2089)

The collision with PATH! syntax is bad (imo), which might support the idea of ISO8601 being the canon date literal. (Though it might clash with URL? :-/)

If pathing a TIME! out of a DATE! gave you a DATETIME! (or an ISO8601! ?) that's not necessarily so bad. For those who would complain that evaluation throws away prettiness, there are much simpler examples like when a WORD! is translated to a LOGIC!, and true becomes #[true]. Decaying a path to a date format is really the same thing, and a less likely one (I deal with logic far more than I ever have to use dates/times)

But it is, to my mind, something where there has to be a clear design point before adding more lexical syntaxes. It's a hodgepodge right now and there aren't clear principles of "when does it stop".

[Oldes]

Actually Red has much wider support than above mentioned examples, which I found just by accident. I'm not concerned about Ladislav's clash too much, but I think that mold/all could provide basic ISO output. For me is quite important to be able load datetime from foreign source without need to replace chars in it.