|
Exactly, that's what we say. 
|
|
|
|
|
Vunic wrote: But why? Why not we fix this in peoples minds and make them follow a unified type.
Same reason as any dispute in history - people disagree. I view the format from the perspective of importance. I care more about what relative day it is (Mon-Sun) than literal day and place more value on the month (year is obvious) so MM-DD-YY makes more sense, but many would disagree with this because they place value elsewhere.
EDIT: As Richard shows above 
|
|
|
|
|
|
Because it's DD-MM-YYYY, everything else is pathetic
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
As Jochen said, ISO 8601 is the standard - and it insists (correctly) on four digit years, not just two. Remember the Millenium Bug problem and the amount of work that caused?
Just use yyyy-MM-dd and it'll be right.
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: Remember the Millenium Bug problem and the amount of work that caused profiteering that that enabled?
98.4% of statistics are made up on the spot.
|
|
|
|
|
Some of it was profiteering, yes - but a lot was behind the scenes and wasn't.
I spent a lot of time, effort, (and money) in late 90's making sure that all the systems in company I had just joined as Technical Manager (i.e. responsible for everything more complicated than a mains plug) were going to work on Jan 1st 2000, and replacing those that wouldn't. And that meant exhaustive testing on the Unix box that ran the company accounts (Accounts software: fail. Accounts system OS: fail. Accounts system hardware: Oh ![Elephant | [mastadon]](https://www.codeproject.com/script/Forums/Images/elephant.gif) , Oh , Oh , fail, fail, fail. Can I get it back up by Monday?) followed by new software selection, implementation, data transfer, training, and parallel running as well as new software to produce management accounts summaries in a format they could understand.
The reason very little failed on Jan 1 worldwide was that a huge amount of effort went into making sure they wouldn't ...
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
It was a fair bit of both, in truth.
Yes, there was an awful lot of genuine work involved but equally there were an awful lot of "consultants" lining their pockets by spreading the fear.
For my part, I did very well out of it working on a project for a very large organisation to temporarily migrate their ERP system for the two years across the millennium because SAP were reluctant to guarantee millennium compliance. Was that money well spent? I rather suspect that any problems arising from not doing it could have been sorted out by a bit of overtime for the finance team. Either way, I was rather glad that developers of yore were so short-sighted and/or strapped for disk-space!
98.4% of statistics are made up on the spot.
|
|
|
|
|
I am surprised because SAP was touted as the solution to the Y2K problem in the US and was bought by many customers.
|
|
|
|
|
As I remember it (and it does seem like an awful long time ago, now!), they were a bit slow off the mark in making any guarantees - at least in the UK. I'm pretty sure that they eventually did but by that time our client had already committed to take the route that they did - running through the timeline in my head, I suspect the decision was made sometime during 1995.
98.4% of statistics are made up on the spot.
|
|
|
|
|
I also ended up correcting a fair number of serious bugs in my company's software related to this issue. Regrettably, no profiteering on my part, since I was salary. Maybe next time, in the unlikely event its still necessary, when the original 32 bit Unix clock runs out in 2038 
|
|
|
|
|
As I recall, a number of other non-year-2000 bugs were discovered and resolved too.
|
|
|
|
|
|
YYYY-MM-DD is great for historical context but not so great for day-to-day. When you read a date, what is the most important portion of that date to you?
As someone who natively reads a left-to-right language, I believe the most critical portions should be farthest left. I know, currently, it's Tuesday where I live. Maybe I've been super busy for two weeks and missed that May rolled over into June. For me the most important portion is the month. With that single value alone I can immediately orient myself in time - Tuesday, early June, 2018. Viewing only the year, or only the day, can you claim the same?
EDIT: I'm honestly curious (open discussion to anyone). I'm not set on any given methodology; this one just makes more sense to me. Anytime I bring up my reasoning in other discussions I'm dismissed as an American yet they provide no sensible argument to the contrary.
modified 12-Jun-18 4:35am.
|
|
|
|
|
Treat dates likes numbers: The most important parts are the higher digits.
Treat dates like times: The most important part is the hour.
The ISO 8601 format is logical (always a good argument for scientists, engineers, programmers etc) and has not been used before by any culture (avoiding the discussion about which of the existing formats is the best).
|
|
|
|
|
I've heard and understood that logic in the past - it makes a lot of sense from a purely logical point of view. The huge fallacy with this is that humans aren't machines. Generally speaking we remember things in relative terms. You don't remember easily what you did on 29/5/2018 but if I said Tuesday two weeks ago you'd immediately recollect.
This is my entire point (which may be cultural I admit). I remember what I did on a relative day of the week (Mon-Sun) and relative to the month (week 1-4). If you asked me what I was doing 3 weeks ago on a Monday I could immediately tell you. If you asked me what I was doing on 21/5 I wouldn't have a clue. This is exacerbated by the fact months have differing numbers of days on top of leap years being a thing.
This relativism lends itself to the month being the most important factor since it is the "anchor" by which you relate the weeks and days (Mon-Sun).
EDIT: Another way to look at it. You have five criteria for determining absolute date: relative day, relative week, day, month, year. Year is obvious so let's exclude it. I can determine the exact date from relative day, relative week, and month (no need for day). Relative day is universally known - you know whether it's Monday or Friday. Relative week is a bit sketchier but the alternative is absolute day. I would argue more people at least have an idea about the former, but can you tell me the relative day and week of the latter without looking at a calendar?
modified 12-Jun-18 5:35am.
|
|
|
|
|
You do realise that you are talking about time spans now?
Sorry for being pedantic here.
I see your point but being an engineer and developer I have switched to the standardised formats long time ago even in "real" life (e.g. when signing papers requiring also the date).
If you want to target users from all over the world, you have to use a general format understood by (hopefully) all of them. Everybody has to use something new from time to time. I'm not an American but understanding the ISO date format should be no problem compared with the changings to the metric system.
As a developer you are free to provide such data in any or multiple formats. An example might be the posting dates here at CodeProject which are provided as time spans for short periods (hours ago, yesterday) and the date for older posts.
|
|
|
|
|
Dates themselves are no more than a span of time relative to your current. The bigger question is who these time spans are important to. If it's a computer than UNIX time is superior to any of the aforementioned formats. If it's a human then you need to account for human ways in which they judge and measure the format. My argument is precisely that.
It's slightly a goal-post move but to hit on the ISO mention: just because something exists doesn't inherently mean it's right.
EDIT: Off-topic but it's worth mentioning that even though I use the Imperial System for measurement (you have to in the US), I actually vehemently agree with the Metric System being more reasonable.
|
|
|
|
|
You get used to yyyyMMdd. this is often what gets spat out of systems like SAP in text files. It's consistency. I like it as it is readily sortable when held as a string (Not that we should, but it does happen). In particular if I have a bunch of folders, putting yyyyMMdd enables them to be sorted. Trying to find notes embedded in a list of folders formatted either of the other two ways is difficult.
Also, the Japanese use yyyy/MM/dd as their standard format - I am in Japan right now, so I see it all the time. I have it in mind that South Africa does as well.
|
|
|
|
|
おはようございます. IIRC it must be super early for you. My argument doesn't stem from common practices but what makes sense from how humans interpret time. YYYY-MM-DD is great for historical records or things intended to indicate an exact point of time over a long period of time (> 1 year). But people don't remember Monday as 11/6 and today as 12/6. They remember Monday as Monday and Tuesday as Tuesday. This relativism lends itself against pure logic as I mentioned in my other post.[^]
|
|
|
|
|
The most important part is the day. If you have an appointment on the 13th, then you need to know that it is tomorrow. If you think I have an appointment in June then you will likely miss it.
|
|
|
|
|
If I have an appointment on the next Wednesday I don't need to know the absolute day, month, or year. It's tomorrow.
EDIT: Actually in this specific case I see where you're coming from in that if you have an appointment in the future for, say 26/10, the day is important. But at the same time, a month is restricted by 12, a day by anywhere from 28-31. Wouldn't you rather know Wednesday in October (4 options) vs the 26th 4th week (12 options)?
modified 12-Jun-18 15:31pm.
|
|
|
|
|
If dates were alway yyyymmdd (with or without delimiters), it would not be a problem for left-to-right readers at all. Those of us who can read process so much information in the background that it will be adapted to as effortless.
lkie radendg tihs - at lseat for nvtaie Enisglh uesrs.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
One funny observation: We use "Arabic" numerals, reading left to right, reading the most significant digit first. In Arabic, they represent the numbers the same way, reading from right to left, reading the least significant digit first.
In several European languages, including slightly archaic English, there are remains of least-to-most-significant reading: "four and twenty blackbirds". Even in modern German, you put the ones before the tens. In most Western languages, for the teens you put the ones before the ten: Four-teen, six-teen.
|
|
|
|
|
Before IP and SMTP became dominant, there were several alternatives going either way: Largest unit first, or smallet unit first. For geographical locations, putting the smallest unit first (name, apartment, street address, town, country,...) is commonly accepted, and it is reflected in SMTP mail addresses.
And in domain / subdomain (DNS) names. But then, go down to the IP address: Now the largest unit comes first! Telephone numbers are the same: The country code preceeds the area code which preceeds the subscriber number.
In the telephone directory (and most other similar person registries), the family name (larger unit) comes before the person name ... except in Iceland, where phone directories are ordered by first name. Except that at a higher level, it is organized by town.
The empirical evidence suggest that claiming that one way is "the natural" one doesn't hold water. As long as we are used to one way or the other, or a mix of largest or smallest first, then that feels "natural" to us.
A check question: How many accepted my list: name-apartment-streetaddress-town-country as a small-to-big list, without questioning it? It is a mixture: In most large apartment buildings, the apartment number is <floor><apt> - a lagre-to-small unit. In many (most?) European countries you give the street name (larger unit) before the street number: Main Street 12, rather than the US style: 12 Main Street. But even in the US, many places street numbers are not dense but defined in a street/avenue style: 1204 is number 4 between 12th and 13th avenue - and the 12 in 1204 is the largest unit first!
It is a mess. Yet, we manage to handle it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)