A Sensible Date Format

Why do I use a strange-looking date format like

96.Feb.29

or (when more details needed)

1996.Feb.29 (Thu) 16:45:23.7

? This format is actually
quite consistent:
the units of time start from large units (years),
and decrease as you read to the right --
which is already how "Feb. 29" and "16:45" work.
To complete the picture,
the amount of prefix and suffix you include
simply
depends on the amount of context and precision (resp.) you need:

When mentioning the year would be redundant, you omit "2002".
Or, if just the century is being assumed, you leave off "20" and just
use "02.Feb...", and if the year is obvious that leaves us with "Feb...".

At the end, omit the units too small to be relevent:
The seconds are usually left off time-of-day when irrelevent,
just as the hour:minute is omitted when only the date matters.

Comparing to other alternatives

The european date format -- which reverses the order of the
day/month/year -- is
justifiable, since it allows the reader's eye
to quickly pick out the day-of-month (which is what people are
probably most interested in) while still specifying the month and year.
The American date format of
"month/day/year,
hour:minute:secondam|pm",
tries to mimic speech patterns (which is a slightly different mode of thought),
but in practice this just ends up hopelessly muddling everything.

Spelling the day-of-week

Regardless of the particular format you choose,
I've found that taking the extra half-second to
write the month as a three-letter abbreviation,
rather than the number,
practically always makes my message clearer.
Compare "1996.10.17" with "1996.Oct.17",
or "11-9-2001" with "11-Sep-2001".
Smart software will be able to parse the full form, no problem.
Some possible exceptions:

The one time I don't do this is when
making filenames which include a date (e.g. a series of backup files):
crossword20041201.txt instead of crossword2004Dec01.txt.
The computer has no way of knowing
that filename happens to include an encoded date,
so I use raw numbers
to keep the file-listings alphabetically.
(Note that if the file's timestamp won't change, then you don't actually
need to
incorporate the date into the filename,
and you can display the files by date -- e.g. ls -lt, in *nix.)

When the document is going to be translated between languages,
using letters for the month may need to be translated as well,
whereas numbers can be left alone.
Though again, cultural differences about the year-month-day ordering
is still a danger point:
If the month-abbreviation isn't emphasizing the date format,
an translator -- possibly a program -- could overzealously
"translate" the ordering of the digits!

How to get your PDA, website, etc. to use this format

Many programming environments follow POSIX's
strftime
format.
The format string I like best is

%Y.%b.%d (%a), %H:%M:%S

for Year.month.day (weekday), hour:min:sec.
To include a time-zone append %Z to this format string;
for a 2-digit year use %y instead of %Y.

The last, long formula returns
just the date if no time provided (that is, the time is 00:00),
and it returns
just the time if no date is provided (that is, the date is 0, or 1899.Dec.30),
and if both are provided then it returns date+time.

In SQL code:
TO_CHAR(someDateColumn, 'yyyy-Mon-dd (Dy) hh24:mi:ss')
From sql*plus, to change the default display-format:
alter session set nls_date_format = 'yyyy-Mon-dd (Dy) hh24:mi:ss';.
You can also add this line to ./login.sql.
(more format options at http://infolab.stanford.edu/~ullman/fcdb/oracle/or-time.html)

Scheme's (and Racket's)
srfi 19 provides
date->string and string->date,
which use similar format codes but with
the prefix ~ instead of %.

iOS (iPhone, iPad):
Okay, this one is quite annoying:
Settings>General>International>Region Format>Hungarian (Hungary)
iOS decided to conflate the date-format with your region and calendar-language!
I set my region to Hungarian and get the date format I want,
but side-effect is that all calendar apps will now use Hungarian
for the day-of-week and the month!
It's not bad for month (they're close cognates to English),
but I'm now learning that Tuesday is Kedd in Hungarian…
Another side-effect (mostly harmless) is that Safari's search defaults
to google.hu!
(But that site is still smart enough to give me results in English
that are virtually the same as google.com.)

PalmOS: Under the "preferences" program,
select "Formats", and use the pre-set "Japan".

Does this mean Wednesday 0:00 (coming
just after Tuesday 23:59), or is it Wednesday evening (technically,
Thursday 0:00am, and no longer really Wednesday)?

The usual intent is to mean Thursday 0:00;
the way to reconcile this is to interpret "midnight" not as "0:00",
but as "24:00" instead.
So 24 hours after Wednesday 0:00 we have Wednesday 24:00 = Thursday 0:00,
and our meaning for "Wednesday midnight" is rationalized.
(Perhaps "Thursday 0:00" could be called "Thursday daystart"?-)

But rather than allowing doubt or confusion,
it's probably best to phrase your deadlines as "23:59" --
it's unambiguous,
readily understood,
and
leaves no room for argument.

By the way, if you want to make it clear you're using a 24-hour clock,
it's not always enough to use a leading zero (e.g. 08:30),
since times in the range [11:00,13:00) are still ambiguous.
You can consider using `h' as a divider rather than `:', to get 8h30, 11h30, 13h00.

Other reasons

While overall it makes many good points,
it does suffer from one incorrect argument,
saying that we humans should use dates which are
easy for computers to read and compare and sort.
That's backwards --
we should not change our mode of thought
just to make our tools easier to use;
good tools are made to work for us.
Elementary software practice
means having a library function which to parse whatever
(unambiguous) date format humans use;
the programmer calls that library function as needed,
rather than always rewriting code for this task.
...But otherwise, the arguments about reducing human confusion
are right on the money!