01:02:03 AM on the 04/05/06!

[Snyder]

Anyway, it's totally a culture thing. There's really no reason why it should be one way or the other. There might be some small argument for YYMMDD if there was some simple base used in the counting.

From a software developer POV I couln't care less if MMDDYY is a culture thing or not - it's simply a PITA.
The only format that makes sense in this context is a hierarchically ordered one, i.e. DDMMYY or YYMMDD - with the latter strongly preferred. (As DemoCoder said - BigEndian rules!

 

[KimB]

Why is it difficult at all from a software point of view? Wouldn't you typically store the date in a struct type format where order is irrelevant anyway?

 

[London Geezer]

How can it be useful? I can't imagine such scenario. But I've always used DDMMYYYY and other formats are troublesome for me.

Basically when you need to know straight away at what point of the year you're pointing at, having the month first helps more than having a day; it's a very slight difference, but sometimes when we're in a rush, it's more useful to us to pin-point when during the year you "did something", saying the month first gives you an idea straight away of when you did it. Then the day will give you an idea of when in that month you did it.

I'm not making myself very clear am i... But it does make sense.

Example:

A client needs to know when we paid an invoice: if i tell them that i paid it on the 16th June 2006, they'll need to "wait" till i say June, to get a real useful idea of when we paid it. They need to know when in the year we paid it, and the most important part of that is the month, then the second most important part is when in that month we paid it.

See what i mean? As i said, it's a very small difference.

 

[IgnorancePersonified]

You are descibing a conversation and not what is written. In conversation slang is acceptable yet how often do you see comms between businesses written in slang or jive or etalk? The extra micro second it takes to read the next charachters in a sentence - over the next deliminater (most ppl block read anyway)- is not an issue however having to deal with analised regionislation of what should be logical time formats is. There is no logic in writting mmddyy because where do the seconds fit? What other system has a point on the scale where you suddenly reverse the order at a certain value?? Crazy shit.

Since I live in an SI country maybe it makes more sense to me rather than basing a common metric on the length from ones king's nose to his out streched hand

 

[London Geezer]

Don't get me wrong, in my company we deal with documents from all over the world, and it's a mess sometimes when we get letters or invoices from countries that insist in doing it "the american way" (most other countries in the American continent in fact) and practically f**k up the whole report simply because they write 02/08/05 and we have to guess (read: spend time researching through other documents related to it) whether it's the 2nd August 05 or the 8th Feb 05...
Hate it to death.

 

[_xxx_]

A client needs to know when we paid an invoice: if i tell them that i paid it on the 16th June 2006, they'll need to "wait" till i say June, to get a real useful idea of when we paid it. They need to know when in the year we paid it, and the most important part of that is the month, then the second most important part is when in that month we paid it.

I'd usually say "week 24" in such case.

 

[London Geezer]

I'd usually say "week 24" in such case.

... Well you are evil afterall...

If someone would do that to me i'd laugh at them. And all of my office would join me in ridiculing The Guy Who Quoted Me On A Per-Week Basis.
But hey, this is London afterall.

 

[Gubbi]

Why is it difficult at all from a software point of view? Wouldn't you typically store the date in a struct type format where order is irrelevant anyway?

No. Operations on date-times is a lot simpler if the internal format is some sort of timestamp (64 bit integer typically). A lot of DBMS' store date-times as texts in YYYY-MM-DD HH:NN:SS because then they can just treat these fields as char(19) when indexing and sorting and what not.

Cheers
Gubbi

 

[KimB]

No. Operations on date-times is a lot simpler if the internal format is some sort of timestamp (64 bit integer typically). A lot of DBMS' store date-times as texts in YYYY-MM-DD HH:NN:SS because then they can just treat these fields as char(19) when indexing and sorting and what not.

Well, I don't see why you wouldn't just store, say, seconds since some specific date/time, and convert as necessary.

Regardless, conversions in dates/times are absolutely trivial. Since different countries have different conventions for visualizing them, then databases should have built-in code for users to select their own preference on displaying dates/times. I mean, the code required for customizing this is so miniscule, I don't know why anybody should complain.

 

[Snyder]

Well, I don't see why you wouldn't just store, say, seconds since some specific date/time, and convert as necessary.

Regardless, conversions in dates/times are absolutely trivial. Since different countries have different conventions for visualizing them, then databases should have built-in code for users to select their own preference on displaying dates/times. I mean, the code required for customizing this is so miniscule, I don't know why anybody should complain.

Most of the time it isn't a problem - and RDMSes mostly store timestamps as milliseconds from 1.1.1970UTC (or something like that) and conversion routines are used where necessary.
It gets really annoying in those cases when conversion routines become performance bottlenecks and for some reasons you have no way to get around them. Thankfully these cases should be avoided anyway where possible and thus occur very infrequently.

 

[nutball]

Like l-b said, it can lead to confusion, especially in a multi-cultural environment such as teh Interweb.

"Our sources said that G80 will launch on 05/11/06"

Are you excited, or not? Should you buy that 7900GTX tomorrow, or not?

 

[_xxx_]

... Well you are evil afterall...

If someone would do that to me i'd laugh at them. And all of my office would join me in ridiculing The Guy Who Quoted Me On A Per-Week Basis.
But hey, this is London afterall.

Our whole schedule company-wide is based on weeks, don't ask me why. Maybe because of this problem. Of course, only for papers, mail and such. We still talk DDMMYY, but look at any document with any kind of schedule and all you'll see is KWxx (KW = calendar week).

 

[Rambler]

Our whole schedule company-wide is based on weeks, don't ask me why. Maybe because of this problem. Of course, only for papers, mail and such. We still talk DDMMYY, but look at any document with any kind of schedule and all you'll see is KWxx (KW = calendar week).

How does that help? What do you do when you want to determine what date the KWxx actually is? I'd say you'll have to take a look in the calendar or do you know which weeks fall into which months?
It may be nice and clear for making catalogues, but doesn't really help the people working with those documents. IMHO ofcourse.

 

[KimB]

Sure it does. The dating system people use is completely arbitrary. Once the workers get used to the KW dating system, they'll have no trouble connecting a week with a date.

 

[Rambler]

Sure it does. The dating system people use is completely arbitrary. Once the workers get used to the KW dating system, they'll have no trouble connecting a week with a date.

How's the dating system we use arbitrary? It's not like you can determine full date-time from KW.

 

[Humus]

Calender week (plus weekday usually) is a common way to refer to dates in Sweden as well, especially if it's something that's on a weekly basis, like pretty much anything in work/school. It often makes much more sense than to refer to dates in month + day terms.

 

[BRiT]

I'm sure I'm not alone here, but I have come across and had to fix way too many bugs related to using MM-DD-YYYY. It happens when peons try to sort dates fields when they're in the displayable string format. The result is comical.

Expected Output:

01-22-1999
01-21-2001
01-20-2002
01-20-2003
01-19-2005

Actual Output:

01-19-2005
01-20-2002
01-20-2003
01-21-2001
01-22-1999

Now if it was YYYY-MM-DD the broken code would work regardlessly:

1999-01-22
2001-01-21
2002-01-20
2003-01-20
2005-01-19