-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Date/time literals #5
Comments
Rationale for this: ISO 8601 is pretty unanimously understood by developers. For some reason, date constructors in various languages use different parameter layouts and/or naming conventions that mean I often find myself having to lookup how to create a new Date/DateTime object, even if I've been using a language consistently for a while. Having an explicit constructor using a unanimous format would clear up a lot of confusion and avoid having to look up parameters, etc. |
So Elixir does have Date Sigils that work similarly: ~D[2017-08-23]
~N[2000-02-28 01:23:45] This is okay in my book, but I'm not a fan of the overloaded The Elixir implementation is also a runtime thing: the sigil is a function that takes a string argument that gets interpolated at runtime. In most cases, that's probably fine, and does make the whole thing more flexible, but I still think I'd like something parse-time and literal-like rather than just a wrapper for |
I think the As for the format; ISO 8601 seems like a great idea, and it makes it very clear that this is a date. But the thing is that 17 out 27 of the chars in there are numbers, people like me without optimal eyesight might quickly dismiss this as some gibberish probably decimal without actually reading it properly. It think it should stand out even more, maybe with something similar to Crystal's percent string literals i.e. things like
If nothing else, it seems a bit clearer to me than without the parentheses and percentage sign. |
Something that I think a lot of big languages today are missing is Date literals. ISO 8601 provides an un-ambiguous syntax for specifying dates, though the individual components of the date could be construed as binary operations on integers, or map entries with integer values.
To ensure there is no ambiguity, date literals could be prefixed with a
D
(orDT
explicitly for datetimes):Some disambiguation between optional timezone specifiers and map entry definitions is probably needed, though key interpolation would be used anyway, since a DateTime is not a symbol.
The text was updated successfully, but these errors were encountered: