Great in theory, but in practice it would be really tough to implement. A lot of assumptions would be made. For example, what should "01-01-01" be interpreted as?
Also, date format strings are pretty standard. If you ever forget them, just type `man strftime` at the command line.
Precisely. Ultimately, no one is going to use a language where there's no way to output a date in a form that will be sometimes ambiguous. And how often do you really even find yourself printing totally unambiguous time stamps? For my part it's way more likely that I'll output "2-11-2009" than "Monday, January 1st 2004 10:43 EST".
Ambiguous example formatting strings would give an error, as an invalid one does now. I like the proposal, although localization is an issue as the examples would have to be in a concrete language.
Removing unneeded abstractions is positive, specially if you have to deal with conflicting models.
Why would 01-01-01 be a problem? If you're writing a format string in this "format string by example" scheme, you don't have to be able to express every possible date-time in it, just a single chosen one.
Or perhaps force the choice of a particular (memorable) date-time, such as January 2nd, 2000, 3:04 am and 5 seconds?
If you can't unambiguously determine the format from the example, kick it back to the user and ask for a better example. Easy peasy. As it turns out, users are incentivized to give good examples because they want to get work done. They won't provide "01-01-01" as an example unless they want to waste their own time.
The idea might sound good, but the moment localization comes in, you learn that you'd much rather specify your date value in a template with some function like
date_for('de_CH', SHORT, some_date_value)
and be done with it. In Switzerland alone, we have three ways (or four, depending on who you ask) to specify and format a date. Heck, we can't even agree whether the decimal point of numbers should be a period (de_CH) or a comma (fr_CH)
I use a variant of that.. in my code, I have a library that parse dates.. and suppose for instance that I want to know the datetime of today at 9h, I just use:
tonight = mylib.parse("today at 21h")
which is way easier than datetime.now() + some_time_delta
To remove ambiguity, you could say months should be represented by December, days by the 31st, weeks by Friday, and so on. In that way it would be easy to implement and easy to write to. Then the case of "01-01-01" becomes "31-12-99", for example. Still easy to read, still easy to implement.
Pick some date that is perfectly suitable to using in an example formatted date such that the format can be inferred from the example (for all reasonable formats). I propose: 1:23:45pm, Friday, December 31st, 1999, which has the advantage of making it easy to determine whether am/pm should be used or 24h time.
This removes a lot of flexibility, which is the whole point of date format strings. "31st" doesn't give you the choice to print just the number, or the number and its ordinal suffix ("-st," "-rd," etc.). Also, preferably "Friday" should stand for the day, not the week. :)
This is why PHP's strtotime is pretty much my favorite function OF ALL TIME. If I were to marry a programming construct, I would definitely court strtotime. Oh man...
I wrote something like this a few years ago. It's hard to get all the edge cases right, but it works well enough for my purposes. I still use it occasionally as a format string generator - I paste the format strings into my code rather than doing the natural language parsing thing every time.
25 comments
[ 3.7 ms ] story [ 76.6 ms ] threadAlso, date format strings are pretty standard. If you ever forget them, just type `man strftime` at the command line.
Removing unneeded abstractions is positive, specially if you have to deal with conflicting models.
Or perhaps force the choice of a particular (memorable) date-time, such as January 2nd, 2000, 3:04 am and 5 seconds?
If you can't unambiguously determine the format from the example, kick it back to the user and ask for a better example. Easy peasy. As it turns out, users are incentivized to give good examples because they want to get work done. They won't provide "01-01-01" as an example unless they want to waste their own time.
tonight = mylib.parse("today at 21h")
which is way easier than datetime.now() + some_time_delta
or:
cron.setJob(mylib.parse('in 5 mins')) instead of
cron.setJob(560) or for the purist:
const int IN_5MINS = 560; cron.setJob(IN_5MINS);
Pick some date that is perfectly suitable to using in an example formatted date such that the format can be inferred from the example (for all reasonable formats). I propose: 1:23:45pm, Friday, December 31st, 1999, which has the advantage of making it easy to determine whether am/pm should be used or 24h time.
Here's a demo with source (PHP):
http://ramenlabs.com/dbe/
Simple example:
10 Jan 2010 //parser determines that "10" is ambiguous, reads Jan as "month" and "2010" as year. So "10" is day of the month.
Now consider the same date but written as "dd-MMM-yy" format:
10-Jan-10 //Good luck!