The Old Joel on Software Forum: Part 3 (of 5) - yyyy-mm-dd hh:nn:ss

yyyy-mm-dd hh:nn:ss - the safest way?

Is the above the safest way to represent dates as text for locale safe conversion? Does anyone know of any locales where this does not work?

Tim H
Monday, October 13, 2003

This to me always seems like the best way to represent a date anyway, regardless of localization, because it's in most-significant to least-significant order, and thus can be sorted with ease. I think the formats popular in both the US (MDY) and most of the world (DMY) are silly.

Michael Kale
Monday, October 13, 2003

It's the ISO standard but few are the countries that use it.

Least likely to cause problems I would have thought.

Stephen Jones
Monday, October 13, 2003

If it's a Windows platform, use GetDateFormat and GetTimeFormat APIs.

azazello
Monday, October 13, 2003

> use GetDateFormat and GetTimeFormat APIs

Don't, when you send a formatted date from one computer to another where the other may have a different locale.

Yes I think the above is the safest way ... for example I think MS SQL unserstands it no matter what the locale.

Christopher Wells
Monday, October 13, 2003

Sending dates across time zones?

Better specify the zone the date is attached to. Is that GMT?

not required
Monday, October 13, 2003

Excel always understands it regardless of locale too.

Unfortunately, it will reformat it locally. so if you write this format to a .csv file, and load it into Excel, everything will be fine. But if you save the file without making a single change, it will be written in a locale-specific order.

Ori Berger
Monday, October 13, 2003

What is wrong with expressing all dates in UTC Unix Epoch time? I mean if I tell you to meet me at 1066000915, that would obviously be... wait... I can do the math in my head... hang on... almost got it...

m
Monday, October 13, 2003

Yes, as Stephen Jones mentioned, the date format yyyy-mm-dd and the time format hh:nn:ss are part of the international (ISO) standard, ISO 8601, for representing date and times. There are many advantages to using ISO 8601 date and time formats, including natural sorting.

And yes, as one anonymous poster in this thread also commented, dates and times need to be qualified by a time zone, which is also encompassed in the ISO 8601 standard. (By default, ISO 8601 dates and times are assumed to be in UTC.)

Two of the best quick intros to ISO 8601 are:

Markus Kuhn
"A Summary of the International Standard Date and Time Notation"
http://www.cl.cam.ac.uk/~mgk25/iso-time.html

Jukka "Yucca" Korpela
"Info on ISO 8601, the date and time representation standard"
http://www.cs.tut.fi/~jkorpela/iso8601.html

One more thing: if you're working with XML marked up data in any way, the default date and time formats in XML Schema (XSD) and in many XML vocabularies happen to be ISO 8601-compliant.

Aron Roberts
Monday, October 13, 2003

well there are standards for this. a number of them, unfortunately.
rfc1123/822 defines one (used in email). it includes the timezone.
ical/vcal uses another one, yyyymmddTZhhmmss if I remember right. Skip the 'Z' for local time, which is defined elsewhere.

mb
Monday, October 13, 2003

The date and time formats in both the iCalendar (aka iCal) and vCalendar (aka vCal) specifications for calendaring and scheduling happen to be based on the ISO 8601 standard, mentioned above.

BTW, iCalendar is the IETF RTC successor to VCalendar, an earlier, de facto industry spec. There's also an XML representation of iCalendar under development. Jason Grigsby wrote up a handy overview of these calendaring and scheduling specs at:
http://wmf.editthispage.com/discuss/msgReader$7900

Aron Roberts
Monday, October 13, 2003

I use that format myself for internal representations when it makes sense, but I not not use it for presenting to a client unless it is a sorted date list because it is a *machine* friendly and not human-friendly format.

When I am looking at email or today's newspaper or at the calendar at the bank, the first thing I and other people want to know is what day it is. Is it the 13th already? My my, Halloween will soon be here.

Guess what? I KNOW that this is 2003!!! I don't want to be presented with that info first for most cases where I am dealing with the NOW or the near-past or the near-future, which is 99% of my daily date oriented tasks.

Next most important? The month! Least important? The year!

Lazy coders who think little about UI issues will say that 2003 is the most important thing in the world because it allows for sort order to be preserved in a file list by lazilly sorting with qsort() after doing some sprintf()s.

In other cases where sorting is needed, the program itself should be know which field is the year, rather than forcing the user to stare at the year first everytime so the programmer can save a few minutes.

Dennis Atkins
Monday, October 13, 2003

The best way is:

YYYY-MM-DD for dates (four-digit year, leading zero on month and day).

HH:MM:SS for times (24-hour format, leading zero on all elements)

UTC time zone for all data.

This has been in ISO 8601 for years, also in many other standards around the world (apdopted in >90 countries) and now in the RFC 3339 Internet standard.

http://directory.google.com/Top/Science/Reference/Standards/Individual_Standards/ISO_8601/

Ian
Monday, October 13, 2003

While the full ISO 8601 may be a bit cumbersome
(and may have poorly-chosen separator characters),
there is no question that descending order of components makes the most sense (year, month, day, then hour, minute, second) and it is certainly the safest way to send dates between locales.

For local or personal use, however, some leading components could be dropped when obvious - e.g assumed millenia, century, decade, or even year - and some separators may be altered to render a more-comfortable appearance.

In the late 1960s, I began writing calendar dates always as yy/mm/dd (or yy/mdd), but circa Y2K I vowed never again to write a year with exactly two digits. For ordinary dates, where Year-of-Decade suffices to avoid ambiguity, my personal notetaking convention renders today as º3/1013, using a degree-mark. (Ten years from now, I might use '3/1013 .)

Perhaps there is a case to be made for placing the day first, as in dd/mm/yy, but that conflicts with the ordering used for time (as well as the place-value notation for numbers, both integers and decimals). However, since about 1752 [*], in English-speaking nations [**], there NEVER has been the slightest justification for beginning (or ending) a date string with the MONTH!

FOOTNOTE:

* Prior to that era, days were designated by month & day, but years were reckoned by inaugural anniversaries of emperors, monarchs, and rulers - as in "the 14th of October in the third year of the reign of George W. Bush". By such reckonning, next January, the 19th would still be "in the third year" but the 21st would be "in the fourth year" of said reign.

Another example is the the US Constitution, which was "done in Convention by the Unanimous Consent of the States present the Seventeenth Day of September in the Year of our Lord [1787] or the Independence of the United States of America the Twelfth". Had the convention completed its work three months earlier, the 1787 year would remain but "Twelfth" would have been "Eleventh".

** Gregorian calendar adoption date ranged from 1582 thru 1918, in various other nations.

Bruce A. Martin
Monday, October 13, 2003

"the 14th of October in the third year of the reign of George W. Bush"

How about: "the 14th of October in the third year of the reign of George Bush II"?

programming language junkie
Tuesday, October 14, 2003

Re: dennis atkins

"Lazy coders who think little about UI issues will say that 2003 is the most important thing in the world because ..."

Not the most important, but hey dude, it do not require a huge amount of cognitive power to process a date in that format, you may save 1/1000th second of your brain function.

The other obvious reason: 5/6/2003
Is it May 6, 2003 or Jun 5, 2003?

n/a
Tuesday, October 14, 2003

Dennis Atkins writes:

>I use that format [ISO 8601] myself for internal
>representations when it makes sense, but I [do]
>not use it for presenting to a client unless it is
>a sorted date list because it is a *machine*
>friendly and not human-friendly format.

I'm in partial accord with that sentiment. It certainly makes sense to display dates and times in whatever formats are most useful to your customers, given their usage contexts, even if you use ISO 8601 formats internally.

However, when you're preparing dates and times for display to an international audience, it makes considerable sense to use the ISO 8601 formats. They're clear and unambiguous, and don't rely on either culture-dependent date ordering ("6/5/2002" v. "5/6/2002") or language-dependent month names.

That's likely why the SourceForge Web site, which provides services to open source developers from around the globe, displays dates in ISO 8601 format:

http://sourceforge.net/

Aron Roberts
Tuesday, October 14, 2003

You should never force the display format of dates. Leave it up to the user (more specifically use the machine settings)

As far as internal storage use any supported date data types or if using character storage that is when you should use the ISO standard.

DJ
Tuesday, October 14, 2003

>> You should never force the display format of dates. Leave it up to the user (more specifically use the machine settings) <<

In the UK, I see a massive number of computers using the old US mm/dd/yy date format as the users are unaware that the date format can be changed, let alone knowing how they might achive that.

Astronomers have used YYYY-MM-DD date formats for over 200 years (yes, I did mean 200 years) so that the international transer of date remained unambiguous and sortable.

Ian
Tuesday, October 14, 2003

>Guess what? I KNOW that this is 2003!!! I don't want to be >presented with that info first for most cases where I am >dealing with the NOW or the near-past or the near-future, >which is 99% of my daily date oriented tasks.

>Next most important? The month! Least important? The year!

I generally know what year it is too, but the month is the least of my worries. I'm week-driven. I find month-based calendar systems painful. Months are about as sensible as roman numerals. Year boundaries are less of problems because I'm usually on holidays.

Geoff Fellows
Tuesday, October 21, 2003

Strictly the ISO 8601 format places a literal 'T' between the date and time portion.

If transmitting a date and time in a human-readable format (especially if it was XML) which is primarily intended to be parsed I would recommend that one used the W3C profile of ISO 8601 <http://www.w3.org/TR/NOTE-datetime>. If that isn't appropriate then I'd recommend something that used either one of the datatypes defined in <http://www.w3.org/TR/xmlschema-2/> or a restriction thereof.

When a human is your primary audience then it's best to be able to convert to their locale using their OS settings. In a distributed environment it isn't always possible to reliably obtain those settings so the yyyy-mm-dd hh:nn:ss is possibly the best compromise between readability and precision.

Jon Hanna
Thursday, October 23, 2003