OS X, ah yes. Ornery indeed. And there are other chat systems out there, but I really want to hear from a champion who knows one works really well, rather than just hoping it will be better.
The way I see it, BNF is an implementation. Need the design first.
Geomol
Too much discussion about a non-problem?
I can tell, what I've done in the World language regarding date/time input. The date part defines a precise time also (midnight), so seconds from the Epoch can be calculated. Then I allow any time value for the time part, and World convert that to the actual seconds from Epoch, and a final date/time is shown to the user, if you're in the prompt. Examples:
I see no need to put special restrictions on the time part of a date/time value. The final point in time is not ambiguous.
Gregg
Doc's point from earlier is that, for Ren, that implies a computation rather than just a representation of a value.
Doc's point from earlier is that, for Ren, that implies a computation rather than just a representation of a value.
If we follow REBOL's lead, you can enter nonsensical values (though it errors on some).
Geomol
Yes, and some systems using Ren might not be able to do, what e.g. World does. Is it really a problem? If you put invalid data into a system, it fails. Let it fail! (It's the Erlang philosophy again.) Users will then learn to put valid time valus into their date/time data. And if you some day need to talk to a system using time on Mars (where there are more than 24 hours in a day), you can still do that.
valus -> values
Judge the time used discussing this compared to the possible time spent in actual applications dealing with this potential problem. Don't waste too much time.
Gregg
What is the strongest argument against a spec of: opt sign int ":" int ":" int opt frac whether as just time or part of date-time?
This is just how data is exchanged, perhaps with suggestions for useful, standardized semantics.
Geomol
I would allow this also:
opt sign int ":" int
meaning hour:minute. Some systems don't care about the seconds, and the format will be bloated, if that's the case.
Gregg
My spec does that currently, but it is potentially ambiguous. Just looking at data, you don't know if it's hh:mm or mm:ss. Not sure requiring :ss qualifies as bloat. :-)
The biggest reason I support opt seconds is for REBOL compatibility. It is convenient.
Geomol
Yes, convenient, and I think also easier to read for those, who never operate with seconds. "Meeting at eleven hundred." Users of the format just have to know, it's always hours:minutes in such cases.
Gregg
Right, the spec being: opt sign hours-minutes opt seconds
Rebolek
Actually, I'm never sure if 10:20 in Rebol is HH:MM or MM:SS.
Geomol
About my point regarding bloat, I do mean it. :) Figure a system with thousands of hour:minute data being exchanged. If you force seconds in, which will always be 00 in such a system, and it will look like XML with end-tags. It is unnecessary bloat.
If you use Ren to exchange data between systems, where it means MM:SS, and you allow the first part to be any value (larger than 23 also), then it should work too, shouldn't it?
Isn't Ren about what you allow users to write. How they interpret it, is up to each case. A string in one human language might mean something else in another human language, but it's still valid text.
Gregg
It's an interesting problem, because whether hh:mm or mm:ss is expected is based on context. The only way around that is to require all fields. Of course, REBOL made a good call, and it's right most of the time, but I've been tripped up by it a couple times myself. More importantly, you have to explain it to everyone that needs to use it. hh:mm:ss is unambiguous.