ISO format dates work -- just try entering them as due dates :)

More examples of date and time formats are here.

I think the request was as display date. I'm glad that I can enter ISO 8601 dates but I'd like to see ISO 8601 dates as well.
Actually, I haven't noticed the date format that I selected in settings showing up anywhere...I've seen various other formats ("Friday, October 3, 2008 | 14:54" in the upper-right and "Mon 6 Oct 08" in the task information display, "Oct 6" in the iGoogle widget) but no 08/06/08.

I suppose it would be a large effort compared to the minority of people who would want it but I would like for the displayed date formats to be fully configurable as is the case with GNU date, PHP date() (and thus some web apps that use PHP), etc. (possibly with a few common default options, like the ones being used). Usually configurable dates will give either one option or a "short" and "long" format, but it seems there are more than two different date displays in Remember The Milk (though I don't know exactly how many).

I was tempted to start a new topic, since this is originally from 2005.

It would be very nice to have support for displaying dates in ISO 8601 format, YYYY-MM-DD.

Seems odd that you can enter dates in just about any format, but display is very limited. Neither of the options in the registration were ones I wanted to select. :D

I'll join on the "neither looks right" bandwagon.
So far, that's the only thing I've found jarring in RTM, which has otherwise been pleasing.
(I see a post elsewhere that it doesn't affect display, only input, so it probably doesn't matter much for users of ISO 8601 - but it was a slightly jarring question to be asked.)

Display format DOES matter. Google Calendar, which I use, has the same issue. It has happened more than once that I've done mistakes like interpreting the 6:th of July as the 7:th of June. That kind of mistakes can have significant implications.

Anything else than YYYY-MM-DD requires usability intruding thinking and is just plain wrong in cultures where all forms of ??/??/YY are for aliens.

Fix this issue, please.

Yes display format DOES matter.

I have just sent this suggestion in by another route as well. Come on guys, it's not that difficult and it means that RTM is usable outside the US/UK cultural enclave - like Sweden, for example, where the international standard is the standard ... which shouldn't be a surprise! And no, the US way of doing isn't the standard - just one non-standard way of doing it.

dd/mm/yyyy and mm/dd/yyyy as DISPLAY formats both look wrong

YYYY-MM-DD would look right to me, if it were an option

i'm in that US/UK cultural enclave and mm/dd/yyyy _still_ looks wrong :)

I agree: please add a user option for the date OUTPUT format. (The input flexibility is great!) Neither of the two available options "looks right" to me. What looks right to me is "2 Feb 2010".

Where I live all months are used as numbers. When I see "July" I have to think in my mind is it 6? or 7?

In Japanese version of RTM months are shown in numbers.
But I want to use English version and still see months as numbers!!!

"Anything else than YYYY-MM-DD requires usability intruding thinking and is just plain wrong in cultures where all forms of ??/??/YY are for aliens. "

Absolutely true. I want ISO 8601:2004 (and no earlier revision)!

+1

+1

I use YYYY.MM.DD and it's available pretty much everywhere I need it except RTM. Supporting the ISO standard seems reasonable.

+1 ... emphatically

The way that it should work is that if I select ISO 8601 as my date format, all output from RTM should be in ISO 8601 format.

I like the PHP strftime configuration suggestion, above. I also like the long date and short date ideas. Here's how I'd use it:
- Short date: I would select the format YYYY-MM-DD hh:mm
- Long date: I would select the format YYYY MMM DD hh:mm

But a good suggestion to implement that would make additional date formats easier to implement is actually displaying in the user's chosen format. I just did a test and the task displays as "Due: Sun 15 Aug 10 at 04:47" and the reminder came across IM, SMS, and e-mail as "This task is due now: 1. test reminders (4:47AM)" even though I've selected MM/DD/YY and 24-hour time in my preferences. For me, this is very important because I work at night. 12-hour time confuses me, especially when I'm tired.

+1
Please provide the option to display dates: YYYY-MM-DD

Since Android has a date format option (Settings > Date & time > Select date format), it is expect that applications should follow that setting, or not?

+1. YYYY-MM-DD as an option for display format please.

+1, YYYY-MM-DD is the way.

+1 for yyyy-mm-df !

I laughed out loud when I saw : "which one looks right?" in the registration form and though : "none of them looks right. I guess I'll go for the lesser evil then..."

And, years on two digits!? I thought we already went throught that around Y2K! ;)

another +1 for YYYY-MM-DD

ISO 8601 should be default. I'm a bit surprised that RTM is following the standard for time representation (23:59) but not for date, which should be YYYY_MM_DD (Replace the underscore with your own character delimiter).

However, may I suggest a third option which can be "fully customizable" ? I'd really like to be able to make it "YYYYMMDD HHMM". Since I key in a lot of date/time (Support tech in a call center), a delimiter is a lot of keystrokes that I avoid whenever I can.

My 2 cents... :-)

in the general settings, my answer to the question "Which Looks Right" is definitely "neither" (please add YYYY-MM-DD, it's the standard isn't it?)

It seems weird to me that so many people have voted *against* this option. Adding a 3rd option seems like a relatively straightforward task and not likely to cause confusion or problems for anyone. :(

+1 to add the standard. I work across multiple countries and have some long projects - 12/01/13 or 01/12/13 is just too ambiguous. YYYY-MM-DD is the international standard...please!

ISO is not the standard. However, I want it, too. In Germany we usually use "DD.MM.YYYY", and every time a date contains a slash we have to start thinking. For me having YYYY-MM-DD would be optimal because I'm a heavy computer user and programmer myself, but having "DD.MM.YYYY" would certainly help those German folks a lot that aren't computer geeks.

Needless to say that both input and output would have to be supported in those date formats. Anything else would be confusing.

Although this is an old postings over the years, the format of yyyy-mm-dd is a standard and used in many formats of programs. I use it as it is the one sorting scheme that makes sense. Whenever possible I would like to see that added to the What makes the Most sense to you

A huge +1 here.

Here in Canada, dd/mm/yy and mm/dd/yy are terribly ambiguous. While many entities have switched to ISO 8601 dates, the old standard in Canada was dd/mm/yy. Meanwhile, as Canadians we have extensive dealings with the USA, where the old standard was mm/dd/yy. We see dates expressed in both of these formats all the time, and it is very confusing.

ISO 8601 is non-ambiguous simply because nobody writes a date in the form yyyy-dd-mm. It is perfectly clear which digits represent the month and which digits represent the day.

I notice that some people have voted against this idea, and I suspect this is as a result of misinterpretation of the request. For those people, please note that nobody here is asking that RTM should *force* the display of dates in ISO 8601 format on all users. We are simply asking for the *option* to see dates in this format. Those of us who are requesting this option simply want RTM to be as intuitive and easy to use as possible, and the existing date display options are an impediment.

I can only imagine the 70 voting against this don't understand what "ISO date" means and that it would just be another option for date format.

gord.tomlin, my experience (in Ottawa) is that Ontarians use MDY and Quebecois use DMY, but I generally agree with the sentiment: both of those formats are bad because they're ambiguous. If people are comfortable with them, so much the better, and I don't want to take away the option to use them. However, I'm quite comfortable with the ISO 8601 format, and I'd rather that than the options I'm given include it.

I agree with other users that it's odd that the setting
Which Looks Right 14/02/07 02/14/07
doesn't seem to cause the dates I'm seeing to display that way:
Monday, June 29, 2015 | 13:00
in the top right, and
Due: Mon 29 Jun 15
in a Task.

+1 this looks why better 2016-08-01 :D

+1

I can't believe it's 2019 and this is still not done. If this is a non-trivial fix I worry for the codebase.

I'm cancelling my subscription now. A trivial change such as this has gone unaddressed for over a decade. Thankfully there are alternatives I suggest others use those.