You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd also like to see this supported (including formats with seconds and fractional seconds).
Rebolbot commented on Nov 17, 2013:
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 commented on Nov 19, 2013:
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 commented on Nov 19, 2013:
Submitted by:rgchris
I am for this, or at least using RFC3339 as the default representation of time.
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.
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 commented on Dec 17, 2018:
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.
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:
Disadvantages:
Imported from: CureCode [ Version: r3 master Type: Wish Platform: All Category: Syntax Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#2092
Comments:
Submitted by: abolka
I'd also like to see this supported (including formats with seconds and fractional seconds).
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.
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.
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
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.
Submitted by: BrianH
This is a dup of #438.
Red language is able to load iso8601 dates as provided in Ladislav's request:
So it would be nice to have it in Rebol too.
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".
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 thatmold/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.The text was updated successfully, but these errors were encountered: