Idea for date formatting strings | Hacker News Reader

Idea for date formatting strings

notes.torrez.org

20 pointsblasdel22 comments

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)

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?

You're letting perfect be the enemy of the good.

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.

and when I forget "man strftime"?

google date formating (and please, no "if I forget google")

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.

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. :)

All of the things you say can be had by doing things grandparent's way with minor tweaks.

But then you're left with essentially the standard php date format, except instead of one-letter tokens, they're all longer.

But concrete and equal in all languages, which is the point of the OP.

the strftime format is an open standard that's already the same in all languages.

I like this idea.

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.

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.

Here's a demo with source (PHP):

http://ramenlabs.com/dbe/

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've thought of this before as well. PHP's changing syntax for different functions is particularly annoying. Self-documenting is an added bonus.

It actually strikes me as a negative to readability; what should look like a format string instead looks like a static value.

Don't think this will work.

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!

An instance like this is when a Good IDE with nicely documented functions is a huge plus.

so how would you say something like ISO8601 week of the year?

Reply on news.ycombinator.com