|
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.
|
|
|
|
|
The correct way is from left to right, from the bigger to the smaller.
Se our URL:
www.codeproject.com/script/Forums smaller small big smaller even smaller - complete nonsense.
Java has better way as com.codeproject...
It makes lexical sorting easier, too.
|
|
|
|
|
The best convention is the number of seconds elapsed since 01.04.1972 : sssssssssssssssssssssssssss. No problem by export / import.
|
|
|
|
|
Obligatory XKCD[^]. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I see you, and raise you xkcd: ISO 8601. No need for an additional standard. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
The USA already don't give a damn about several international conventions. A unified date format would fall into the same pit.
|
|
|
|
|
Right - because they don't follow the standards you prefer.
Silly person! China still doesn't have an alphabetic language and working on changing that would be time better spent (although they've had civil wars over that in the past).
Let me remind you that the US use of 'ounces' is better for computers.
1 oz = base unit = 8 drams
4 oz = gil
8 oz = cup
16 oz = pint
32 oz = quart
128 oz = gallon
All powers of two - perfectly represented in binary. Perhaps you ought to get over counting on your fingers and trash that roundoff-error-prone metric system.
| 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 |
|
|
|
|
|
Except in scientific calculations, base 10 is the way to go. That goes even as far as the US scientific community using the one and only worldwide base 10 system, namely SI/metric, because it is objectively superior to the imperial system. As for "better for computers", your claim works only as far as integers reach and in scientific (or pretty much any real-world) calculations, we need floating points and then the advantage is out of the window as you can't just shift the register to convert from cup to oz, you have to do proper calculations with the bit pattern. So, no. Just no.
As for China, so what? We're talking measurement systems here, not languages. Although one could argue that English already is the worldwide standard language and China is indeed slow to catch up. Which reminds me, on some other forum, I see Chinese people ranting about them having to learn English instead of the ROW having to learn Chinese. Let's be real here, the topic isn't even about Chinese being a better or worse universal language than English, the topic is that we aren't on a green field here, there's tons (literally, as in "printed paper" and figuratively as in "plain and simple loads of stuff written") English research material and technical documentation out there and having to rewrite/translate everything in Chinese simply isn't viable.
My personal gripe is the date format, even in Germany, where I live. The ISO 8601 date format is objectively superior to Germany's dd.mm.yyyy, but that doesn't mean people are using it. Although, there's light through the clouds, the ISO 8601 date format was crowned as officially accepted on official government forms. Now I'm just waiting for everyone else to catch up.
|
|
|
|
|
Silly person.
The problem has been solved. It was agreed that we will return to the English system of weights and measures, except for the date, which can be yyyymmdd . Clocks/time may be 12 or 24 hr in informal conditions, the 24 hr clock only used for object data storage.
So sit back, relax and "enjoy a pint!"
| 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 |
|
|
|
|
|
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)
