Family wrongly accused of uploading pedo material to Facebook – after US-EU date confusion in IP address log A family in Spain was erroneously accused of uploading child sex abuse material to Facebook because Spanish investigators read a date in a US report as if it used the European date format. According to a report in El Pais this month, Spanish authorities received a report from the US-based National Center for Missing and …
Nitpick, it's the International Organization for Standardization. Known in French as the Organisation internationale de normalisation, and intentionally referred to as ISO, which matches neither, because to call it IOS or OIN would be to give one language precedence over the other and probably upset the French.
And yes, it would be good if companies used standards for things like dates and phone numbers. In my experience, European businesses tend to use the standards, and US ones tend to assume everything is American (or perhaps, to be unaware that anything non-American exists). When emailing my US colleagues I always write dates out with the month by name.
...and if you were [un?]fortunate enough to spend part of your childhood in a British Commonwealth country, subsequently returning to the US, you use them interchangeably and don't care!
Dates in slash format always require a little extra thought.
"Color" and "neighbor" seem to get spelled the US way (most of the time at least), but "standardisation" usually comes out the UK way
Spelling in the US of A was deliberatly broken afteer the rebels dumped the tea in the harbour - it was intended to show that, although they spoke, nominally, the same langage as us original English speakers, they were no longer us.....
IIRC S and Z in Engerlish English reflect the Latin or Greek origin of the word (in theory) - which again was largely a "we aren't them" type move on behalf of the Romans (though between aristos and peasants)!
plus ca change and all that... language is fun.
/mines the one with publications by Cawdry, Johnson and Noah Webster falling out of the pockets
I have been led to understand that the joke about the Stonehenge monument being in danger of being crushed by a dwarf (This is Spinal Tap) happened because we Murricans also swapped the meanings of " and ' for feet and inches for the same reason: spite.
I didn't even know about the symbols being swapped until a friend pointed it out. And suddenly I understood the joke.
I remember learning the two symbols as a child and thinking that it made more sense for " to mean "feet" and ' to mean "inches" because " was a larger symbol and feet is a larger measurement. But what would a child know about sense, eh?
Spelling was hardly consistent even *within* England until relatively recently. With events like The Great Vowel Shift (1400-1700) messing with pronunciation, and spellng being closely related with pronunciation, and all the different accents within England, how things were spelled depeneded a lot on where you lived. Whether the locals used a word that came from French or from Norse for the same concept made a big difference.
The people who came to the US came from different parts of England, and at different times, and they brought their accents with them.
Just kill the stupid US date format.
I don't mind them keeping inches, Fahrenheit, the confusing pounds alone for body weight or their spelling. Or their own names for things.
Though I try to either write the month or use YYYY-MM-DD. I now use YYYY-MM-DD on all my spreadsheets etc.
"I don't mind them keeping inches, Fahrenheit, the confusing pounds alone for body weight or their spelling. Or their own names for things."
That is ever so magnanimous of you. Thank you for your permission. In return, I'll allow you to keep spelling things in the French manner, instead of in proper English like wot we do.
As for other bits & bobs ... How many stone do you weigh, exactly? And what are the dimensions of your favorite cricket pitch? How many miles between York and Leeds? Lovely thing, that metrical system, eh?
Look, why don't the two of you compromise.
@jake - you can start by admitting there's a fucking H in the word 'erbs
We'll accept that you say Aloominum because that's what it was originally called, and we amended it to make it match other element names
I once landed a gig with US-based company. The bit of paper I thankfully had in my hand specified a start date of "1st December yyyy". When I turned up at the office, HR tried to kick me out, saying I wasn't expected until 12 January, conveniently ignoring the change of year number...
We'll accept that you say Aloominum because that's what it was originally called
As ever, things are even more complicated than that. From the webelements site:
In 1761 de Morveau proposed the name "alumine" for the base in alum. In 1807, Davy proposed the name alumium for the metal, undiscovered at that time, and later agreed to change it to aluminum. Shortly thereafter, the name aluminium was adopted by IUPAC to conform with the "ium" ending of most elements. Aluminium is the IUPAC spelling and therefore the international standard. Aluminium was also the accepted spelling in the U.S.A. until 1925, at which time the American Chemical Society decided to revert back to aluminum, and to this day Americans still refer to aluminium as "aluminum".
Someone else can explain why our transatlantic cousins dithered in 1925.
Ah thanks, that was closer to the version I had in my head when I googled to verify before and found a different answer.
Although ISTR Webster spelt a word wrong in his dictionary and the US still uses the mistake. Must not have been Aluminium though
I grow lots of herbs ... I've always pronounced the h. Was I not supposed to?
I say aluminum when I'm talking to my fellow Yanks. I say aluminium when I'm talking to most of the rest of the planet. I spell it alumin(i)um here on ElReg, so the silly-arse pedants can't claim that they don't know what I'm talking about, even though they clearly do. Similar for colo(u)r, favo(u)r, flavo(u)r, and etc. Sometimes I'll throw in an Oxford comma, just to piss 'em off :-)
And when you boil it all down, Shirley it's a matter of getting your point across in a forum like this, regardless of how you spell it.
One thing we can all agree on ... I'll get the next round in. Pints, of course, none of that Metric shit.
I've been more places than you've had hot dinners, as they say.
20 US fluid ounces isn't a US pint. It's 20 US fluid ounces. Check with federal weights and measures.
It is however slightly larger than an Imperial pint. I'm undecided whether I like the extra 23ml or not.
Either way, 1 litre is definitely too much beer in one go.
They[0] are very probably incorrect, as usual.
If you walk into a bar here in Northern California and ask for a pint of whatever is tasty today, you'll get 20oz of beer. If you bitch that it's either 4oz or 23ml too much, you'll probably be shown the door under a shower of peanuts. And quite rightly.
A litre of beer sometimes hits the spot quite nicely.
Being a childish pedant is no way to get a beer bought for you.
[0]Whoever "they" are ...
But there are two "a"s in "caramel", and they are both pronounced. It's from the French "caramel", meaning burnt sugar (16thC). The French stole it from either the Spanish or the Portuguese, and then the etymology gets somewhat murky (Source: my Big Dic[0]).
Carmel is a town in Northern California known for beautiful but mediocre aging golf courses, expensive but very tasty food, tourists willing to shell out the big bucks to drive through a residential neighborhood, and a former Mayor packing a .44 Magnum.
Crammel (or cramble) is an older word from North Western England meaning to move with a gimpy gait. (Again, according to my Big Dic.)
[0] OED, second dead tree edition.
Again, burnt sugar is pronounced "caramel" in the US, while Carmel is a town in Northern California.
Me sister's Yorkshire born FIL and all 'is mates say 'erbs. Everybody I know in California says "herbs".
Most of you Brits call Aluminum "Tin" ... as in "I'll get a few tins in". And of course in Oz it's a "tinny".
Insert something pithy about glass houses here.
"the one that always annoys me is "sodder" - the word is solder and the 'l' is pronounced."
I believe it was Henry Watson Fowler who wrote "solder without the "l" was "The only pronunciation I have ever heard, except from the half-educated to whom spelling is a final court of appeal ..." and was baffled by the OED's statement that it was American.
As the OED puts it (paraphrasing to avoid copyright hissy-fits): The modern form in English is a re-Latinization from early 15c. The loss of the Latin l in that position in Old French is regular, as poudre from pulverem, cou from collum, chaud from calidus.
Never mind bodyweight, they use pounds alone for everything, no matter how ridiculous the numbers get. They will tell you with a straight face that the cargo capacity of a C5 is 281,001 lb or that the Statue Of Liberty stands on 54,000,000 lb of concrete.
INT: COLONEL STICKLER'S OFFICE - DAY
COL STICKLER
What do you mean you accidentally left your packed lunch in the cargo bay? That was a max-load test flight! You could have crashed the plane!
SGT LOAFER
Well, it didn't crash, did it.
COL STICKLER
Hmmm, no. I guess the max load is a pound more than we thought it was.
That capacity is a paperwork thing, to be used if they need a scapegoat for an accident when carrying heavy loads. In reality, the plane can carry quite a bit more than the listed maximum (see: fudge factor). Professional pilots know how far they can push their aircraft in an emergency situation. Professional aircraft maintainers know that the airframe & engines will need a good looking at immediately thereafter.
Note that as the size of the aircraft drops, the smaller the percentage that one should exceed the listed gross takeoff weight by (usually) ... to the point where with most single engine general aviation aircraft, one should always treat the listed max weight as a hard limit.
Well, given that much of the world drives on the right side of the world, it's the Englishers who are wrong this time (with this driving on the left business). Even the Swedes saw the light in 1967 and decided that it'd be best to drive on the right side like their Scandinavian brethren and the rest of Europe (the poxy island off the coast of Belgium and France excluded).
The Southern Africans and South Asians have not yet twigged that maybe it'd be useful to drive on the right side, which makes border crossings always... errr... fun. ;-)
Just kill the stupid US date format.
Even as an American, I dislike the US method of writing dates. It's neither Big-endian or Little-endian, but rather scrambles the sorting order entirely. For that matter, when it comes to proper sorting order, I prefer YYYY-MM-DD (or YYYY/MM/DD) as that's immediately obvious for intent, as well as readily sortable.
Otherwise, if I need to write out a date I need to send someone, I'll use a YYYY-mmm-DD (3-letter abbreviation for the month) or YYYYmmmDD.
As I professionally correspond with a lot of Germans, I have largely adopted their traditional format dd.mm.yyyy (sometimes they, but not I) even use d.m.yy to add to the confusion.
At least in our case context helps - most rent houses one or 2 weeks, and I always have "from" and "to" dates.
>until English becomes the de facto standard language on the planet.
Depending on politics, birth rates and the 4 horsemen, the de facto language may end up being Chinese, Russian, Arabic, Hindi or any number of others
The date stuff will be a clusterfuck until Excel has a tool to swap format without altering the digits in the string displayed. Am fed up from importing a spreadsheet with it set in USian into a UK spreadsheet and it borking the whole lot
"until Excel has a tool to swap format without altering the digits in the string displayed. "
There are literally so many ways to deal with this via formatting, functions or scripts and they have been there in Excel for roughly three decades. I can only assume that you're a geneticist.
> I can only assume that you're a geneticist.
I'm not, but still haven't come across such tools. Formatting doesn't cut the mustard - sure you can swap from mm/dd/yyyy to dd/mm/yyyy, but if you've already got a date in there it preserves the internal "days since 1/1/1900". If I've accidentally typed 1/3/2020 for first of march but Excel stores it as USian, converting the format to UK will have it read 3/1/2020 when I wanted it to read 1/3/2020.
Functions? Which ones? You could mangle it by extracting day/month/year via the functions of the same name, and then reassemble while swapping day and month around, but that doesn't strike me as elegant (summat like "=date(year(a1),day(a1),month(a1)")
Scripts - sure I could write some VB to do it, but it's only happened enough to annoy me, not regularly enough to warrant making a custom macro that I store and add to spreadsheets when I need to deal with it.
Happy to be told if I've missed something
Personally, in most cases I'll use DD-MMM-YYYY (e.g. 12-Jan-2020) or some close variant, which makes sense to everybody (well, English-readers, anyway) while being unequivocal and brief. If it's a filename or something else that needs sorted I'll use YYYY-MM-DD or similar (if it's likely to be sorted I'll use leading zeroes as well). Obviously if a form specifies a format I'll use that format. Sometimes if I'm filling in USian paperwork I'll use MM/DD/YYYY, but only if it makes sense to, and I'm always conscious of it.
I grew up with MM/DD/YY but I've experienced considerable enlightenment since then.
But I will give up my weird measurement units when you pry them from my cold, dead hands. The metric system is the work of the devil! My car gets 82 rods to the hogshead, and that's how I likes it!
We need an icon for Old Man Yells At Cloud.
Last time I had to fill in US entry paperwork (many years ago now), I recollect them specifying DD/MM/YYYY for the dates. I assume they did it that way because so many people visitng write it like that without reading the form more closely and it made their life easier when processing.
The US came close to going metric in the 70s, then had second thoughts around automobile tooling or such, and backed out.
There are still a [very] few metric distances on road signs around here. Now, our autos are all metric anyway, since they're sold worldwide (the good ones, at least) or are owned by foreign companies. However, we stubbornly cling to the imperial system of inches, quarters, eighths and sixteenths (and sometimes thirtyseconds) for our tools. And have to have two sets.
I've been an engineer (electrical) for over forty years, and I will probably be dead before this country goes metric. Anyway, at the moment, we have bigger problems...
// 10mm box wrench in the pocket
However, we stubbornly cling to the imperial system of inches, quarters, eighths and sixteenths (and sometimes thirtyseconds) for our tools. And have to have two sets.
You must not be working on old British cars then, otherwise you'd have to have a Whitworth set as well.
There are multiple "language" options for software that are independent of each other:
1. UI language -> what the menus, dialogs etc are displayed in
2. locale -> basis for units such as dates, temperatures, weights and measures
3. doc language -> for instance a word processor can display, edit and proof text from dozens of languages in a single document, although you might need to download add-ons for specific tasks such as Finnish hyphenation.
Problems (usually worst in Anglophone countries, but officially multi-lingual places like Canada and Switzerland have their own issues)
1. (not as bad as before) Manufacturers distribute computers with US English settings that are never reconfigured by the user or IT department to meet local expectations. Consequently every bit of software subsequently installed reads the system default and matches settings.
2. Vendors confusingly conflate the different language settings, often using the locale names (e.g. English (US), English (New Zealand), French (France), German (Switzerland) ) in place of language names.
3. Browsers download as US English and ignore the system settings. Each browser has its own complement of language and locale settings to cover date display, spell-checking etc.
4. Online software is generally worse at handling this than desktop software. For instance Microsoft 365 seems to have US date formats hard-coded all over SharePoint, OneDrive, Teams etc so that any string 01/02/03 could be a dd/mm/yy or mm/dd/yy depending on the browser you open it in or indeed if you open a document in a desktop app rather than online. Google. Apple, Facebook and Amazon have similar problems across their platforms and services. Websites also perform weird redirects based on language to subdomains in different locales.
5. Most of the developers (even in open-source land) are in the US and cannot be bothered fixing bugs to do with non-US issues. There are bugs in Chromium relating to such stuff that go back over a decade, and are constantly merged and deferred.
Luckily (in Linux, anyway) it is easy enough to create a locale that as a default holds whichever formats you choose.
IIRC I copied the date format (LC_TIME) from the Danish version, created the LC_ADDRESS using an editor, etc.
Been working that way for over a decade.
When emailing my US colleagues I always write dates out with the month by name.
I use ISO format. I know that most of the time the merkin colleagues will misunderstand it, but that's their problem. Just like they always assume time is in one of their timezones. Some are slowly learnning about time. With date, its much rarer.
"French"
Isn't it time for the ISO to rule on languages and put the final nail in the coffin of archaic minority languages and acknowledge the global acceptance of English. It may not be number 1 as the global first language (yet) but it certainly is for the combined figure for first and second languages. While they're at it perhaps they could give some spelling advice to Americans.
As for dates: think of the sort order. yyyymmdd is so much easier to deal with. Think of the environment: how many gigawatts are wasted by computers converting dates to yyyymmdd to sort and then back to suit local preferences?
And shouldn't we use yyyyymmdd to save our descendants from a recurrence of "the millennium problem" at the end of 9999?
As my father-in-law says, the most spoken language in the World is bad English.
The problem with English is that even with the huge number of words (Anglo-Saxon for the animal in the field, French when cooked) it is not terribly good at expressing a number of things. "Hygge" I think was never really understood, and try "saudade" from Portuguese.
The English language strategy is usually to borrow the foreign word, otherwise there is no special need to have a single word to express every concept. Some languages will have single words, others will have compound expressions and others use phrases, e.g. English "ninety" vs the French "four times twenty plus ten".
A phrase translation is more than adequate. That's why I get peevish about articles on "words that can't be translated into English" which then proceed to translate all the foreign words into English. The article title should be "words that have no single-word equivalents in English".
I work in IT and date formats have ALWAYS caused issues.
EXCEL of old was terrible you could never predict how excel would identify the date and it seemed to ignore the computer region settings. It might be a bit better now but we resorted to formatting the date with a month as words. That ways almost always worked, Excel found it impossible to mess it up.
What idiot though that the America standard MMDDYYYY was a good idea?
A.F.A.I.K it is basically just the USA and a few random countries, EVERYONE else uses DDMMYYYY or YYYYMMDD. This may not have been that important 100 years ago but now it is a total mess and with so many US companies (Microsoft I am looking at you) doing a very poor job of making their software work in other regions.
My current company uses some rubbish America software for HR and they think i have Vacations. I am British so i take HOLIDAYS NOT VACATIONS.
So little interest in doing the right thing and assuming that the way America does this is the right or correct way for all countries.
Our liberty is at stake because those that should know better make stupid mistakes that are then reinforced by a system that decides to hide mistakes rather than self discover them before taking action to disrupt peoples freedoms.
I'd like to see all agencies, companies etc, government public or private, annually disclose all data that they processed on people to those people.
I'm sure we all would be surprised and alarmed at the amount of data collected on us & the reasons for processing that data and will all want stronger controls.
Its this work going on in the background behind our backs that is the most dangerous as we individually have no oversight or ability to correct mistakes, often no ability ever to correct mistakes.
Address shouldn't be used as evidence. Like the old story of a IP being on a list of movie or music pirates. That IP address turned out to be a printer.
And with the ability to break into anyone's home wifi, you could easily set anyone up. "It came from their IP address, so must be someone in that property and couldn't possibly be the person sat outside in their car with a big aerial on the roof"
Yes, time to switch to IPv6 and fixed prefixes and addresses for everybody, so good-bye to "plausible deniability" for movie and music pirates... like it or not, IP addresses are and will be used - of course as long as they change who had which IP must be carefully checked.
Anyway in most contracts - at least here - the users accept full responsibility for what their networks are used for - and it was the same before with telephone lines too. If you have lame security you may not be able to use it as an excuse for illegal uses of your connection.
To get the VoIP credentials for my line to use my own devices instead of the ISP-supplied router, I had to specifically sign and accept responsibility for any illegal access to my line.
I call that an unenforcable contract clause.
Given that many domestic routers are controlled by the ISP not the service user(s), and the frequent discovery of router security holes, as well as the ability to discover, connect to and compromise a router from outside a service user's property, there's no way a user could provably be liable for what happens at their router.
It's already been enforced, don't worry. You'll need to prove you've been hacked - the fact a device could be hacked is not enough. If your car kills someone, you'll need to prove it was stolen, otherwise you're in trouble. The fact a car can be stolen, and cars are routinely stolen, is not enough.
It's like the excuses of people posting something very wrong on Twitter and then claiming their account was hacked.
Internet is not a place where you can do anything without any risk to be identified and persecuted....
Just because it has been enforced doesn't make it right.
And in your example the prosecution has to prove it was me driving my car, and not someone else. Burden of proof is on the prosectution, not the defendant. At least in this decreasingly civilised part of the world. For now.
Yes, the cops will give me a hard time and I'll have to provide a strong alibi or evidence that I wasn't involved, but it's still on the prosecution to prove I was driving.
But all this is deviating from the point that an IP address alone should never be considered reliable evidence of someone's involvement or culpability.
As the owner of the car you're in most legislation responsible for what the car is used - and it's up to the owner to demonstrate the car was used by someone else. "Ownership" usually implies responsibilities as well.
The burden of proof is on the prosecution, but laws also assign specific and implied responsibilities in many situations - and it's up to the defendant to demonstrate someone else was actually responsible. Think about someone who sign a balance - if it is found false, you're responsible unless you can prove someone deceived you and gave you false numbers.
I think you are mixing up criminal, administrative and contract liability.
Yes, contracts may mean that you are financially liable for many things, including the responsibility to pay your ISP bill even if your router was hacked.
However, in criminal cases, the responsibility is with the prosecution to prove it was you. Often that is not an issue because the person does not deny they were the one performing the act. However, if you claim your car was stolen or your WiFi was hacked, you do not have to prove it - the prosecution have to prove that it was you. Of course, in practice, they have to prove it to the satisfaction of the jury, and the jury may have a tendency to believe the prosecution unless you expand on why they are mistaken.
Administratively the line is blurred. For example, if a speed camera catches your car, the registered keeper has to provide the name of the person driving, or some other explanation, or else they will be held responsible. But if the issue ends up going to court, the usual legal burden of proof still applies and the prosecution will do things like produce the picture, explain that this is your usual route and time of going to work, etc to convince the judge/jury it was you.
In this particular case, of course, the problem is not prosecution - that seems not to have happened - it is all the disruption caused by the actions of the police and prosecutors who didn't clarify the ambiguous information they were given.
This post has been deleted by its author
"If you have lame security you may not be able to use it as an excuse for illegal uses of your connection."
It depends on who "you" refers to. If it's a business then there should be an expectation of reasonable care being taken to defend the network and factors such as size of business, number of data subjects and amount and sensitivity of data should determine what's reasonable. In the case of a private household it's more reasonable to look on the householder as victims in the case of an intruder.
None of that, of course, excuses sloppy investigation.
You do realise a contract can be deemed unlawful. Years ago I bought a digital camera, I think in 2002 or round that time from Kodak on their online store. Someone made a mistake and put the wrong price. I'd checked out and paid and they'd given me a receipt. Now technically a contract. For everyone that ordered one they later rejected as a mistake, saying they had a right under their contract blah blah. It was deemed later, that their contract could infact be illegal and void. They eventually, as a "good will gesture" honoured all the orders.
The camera ended up being shit but was fascinating having an early digital camera.
So contracts can be deemed illegal if challenged.
Actually, DD-MON-YYYY (or YYYY-MON-DD if you want it reversed) is superior - it means that you can look at the date and be certain that the month and year you are looking at is indeed a month and a year.
Remember, you may know what your data means, but other people aren't you.
Yes, MON will be different in different countries. Localisation exists - this is not a new problem, and in this case the localisation will be obvious. With MM and DD it isn't always clear.
Dates are generally stored using a date/time variable, so sorting is only really an issue when you insist on storing your date as a string (or indeed, embedding it in a filename) - in that case yes you should use YYYYMMDD, but that should be an exception.
Thank you @Steve Davis 3 - I did not know that.
@Dr Syntax: Yelling I S O is missing the point. The ISO standard is great if absolutely everyone follows it. But not everyone does, and you cannot tell if an arbitary date is using it.
The rest of you: The whole point here is that MM and DD are being confused because unless you *know the date format being used* you cannot distinguish between them for the first 12 days of the month in any arbitrary date string. My point is that MON removes that ambiguity.
"The whole point here is that MM and DD are being confused because unless you *know the date format being used* you cannot distinguish between them for the first 12 days of the month in any arbitrary date string. My point is that MON removes that ambiguity."
The ISO format YYYY-MM-DD is unambiguous. As soon as you see that sequence of 4 digits - 2 digits - 2 digits you know exactly what the date is. This is because there is nowhere in the world that has ever used YYYY-DD-MM as a date format.
If the ISO standard is being followed anyone who mis-interprets it has only themselves to blame. The significance of ISO dates is that (a) they collate properly and (b) they are natural language independent.
If I'm writing up genealogical or historical stuff I do, in fact, use something like 15 Sep 2020. It doesn't have to be collated and the whole text is in English so language dependency of the data is a minor issue.
Dates as data are an entirely different kettle of snakes.
My database engine of choice is Informix which, internally, stores dates numerically where 1 is the first day of the last year of the 19th century (nobody explained it to them) and you can have that converted in a large number of ways depending on language settings and an environment variable. Spreadsheets should work in similar ways and switch representation on demand.
But get into historical dates and if you're lucky all you have to worry about are Julian/Gregorian changeovers and hope that the first part of the year it was written out unambiguously, e.g. 1731/2*.
If you're unlucky you end up with something like: "Friday before the Feast of the Apostles Philip and James in the fifth year of the reign of King Edward" or even worse "the Friday in Pentecost, in the year abovesaid" and hope that some kind editor has done the hard work of translating it all. And if you're really unlucky you find that the kind editor hadn't noticed that a whole year's records were missing so all the dates were mistranslated**.
* I came across the work of an antiquarian who avoided that - I suspect as a deliberate choice - so he recorded a will dated and proved (i.e. testator died between the dates) apparently several months before he was being sent instructions for his part in the latest episode of the Hundred Years War.
** Several hours with an Easter calculator, Googling of saints' days and cal to sort it out.
So in a sorted list you're fine browsing through the entires in :
April
August
December
February
January
July
June
March
May
November
October
September
order? Also saying that dates are stored using a date/time variable ignores that that also has conversion issues, unless the system 1) knows which date system the source system used, or 2) the date variable uses the ISO format for consistency, which causes all kinds of issues as anyone who's experienced working with dates in SQL can attest.
No - if you are sorting the date as an ascii string or filename then you do need to use YYYYMMDD - I even said that in my first post!
And the rest of your point is simply restating the problem: If we do not know what format was used for the dates then if we are using DD and MM we can't tell. My response is that we are using MON then it is immediately obvious which the month is.
Oh, been processing dates for nigh on 37 years - even before I worked on SQL. Well aware of the problems, thanks.
and then you try to sort the column by date order and it all goes wrong as well.
Shows, despite the size of the company their thinking can still be stupid. In a large company you'd hope there'd be more people who'd say "hold on that doesn't work", but instead there's just more people who don't want to get involved.
«"a large US firm I used to work for insisted on this format everywhere"
That's because they didn't know any better.»
Well, they are a US company. They probably also assume that every one of their customers everywhere in the world has a "zip code" (with a specific format), that there is never any need to specify a country code for phone numbers, that said phone numbers absolutely must be able to be hammered into a nnn-nnn-nnnn format, and that producing product description sheets with measurements in squiggles and ozzes would mean anything to anyone else… (It's particularly disheartening to sometimes see that last for products from Chinese companies in their product illustrations on $well_known_international_shopping_sites, which probably means as little to them as it does to the majority of their worldwide customers.)
Add to those complaints the assumption that every address belongs to a city and customer address formats are structured that way. There's even less excuse when genealogical S/W is written that way to the exclusion of fields that would be more relevant such as townships in England and townlands in Ireland.
And while we're on the subject of addresses I'll add the online ordering S/W of a German car parts site that couldn't cope with the notion that some addresses don't have a street number. I don't know if it's coincidence but ever since that mess hit them one particular courier had been unable to deliver anything here.
a German car parts site that couldn't cope with the notion that some addresses don't have a street number.
You're lucky, until a few months ago my address didn't even have a street name. They finally had to roll them out across the village and hamlets because the fibre planning database requires it.
11Oct16 format would have been fine until the year 2001; before then 11Oct98 was totally unambiguous, and it will be in a dozen or so years time when 11Oct32 is also unambiguous, albeit subject to suspicions of typos. For the current span where day no and year no overlaps, it's not unambigiuous.
We have all seen the joys that converting between metric and Imperial system brings (even if the latter is defined in the former). Wherever such different notations touch and interact there is the potential for confusion, loss of property, injury and life.
In this case as well, it's probably good that nobody lost their life and things should get sorted out over time as presumably red-faced officials are forced into admitting the mistake. Yet it could have been so much worse.
Imagine a US-trained nurse, misinterpreting a date given on medical equipment or files in a Spanish or Korean hospital? Decades of learning to interpret date strings as MM/DD/YY(YY) when the rest of the world does not use that format is just begging for serious mistakes to be made. Like with medication or examination intervals.
Without further context provided, what dates would 01-02-03 or 01-02-2006 be? Former (sadly still common) format could be anything from the first of February, 2003 to the second of January, 2003, to the third of February, 2001. Latter could be the first of February, or the second of January.
Why do we accept such an obvious liability?
Limey of a diabetic wife -
Her blood test meter uses mmol/L while the US uses (quick Google search) mg/DL.
According to Google, we limeys are the odd one out, I thought it would have been the Yanks - but I think the point is that it's not only date format that can be a problem.
Personally, I think blood sugars should have the same format as tea sugar - tea spoons!
"How many sugars do you want in your tea/coffee?"
"10 mmol/Ls please!"
I don't disagree – perhaps I should have said "the other way around". I just mean that almost everyone will think of it as backwards and hence will keep using whichever format they currently use. In informal contexts – e.g., "Let's have a meeting on 23 September" – the day of the month is often most important, and anything following is probably less relevant. As I noted, I do use ISO 8601 in file naming, even if only for the simple fact that sorting alphabetically then also sorts by date. But I will probably still speak things the other way around. I do, however, maintain that the US way of doing it is stupid and confusing.
I remember following the Usenet (or was it a mailing list?) discussion of the early domain naming syntax in the 1980's (and a LOT of discussion about how it would work with email addressing, including lots of discussion before it was agreed that email to a.b.com would not need to actually flow to "com" then to "b.com" then to "a.b.com") and I do not remember a time when it had the most significant part of the domain first. Was that format a UK or JANET thing or was there really a time when a draft Internet RFC had that format?
Reminds me of when I was at uni in the early circa 1990, my email address was jsmith123@uk.ac.salford which to me made perfect sense, as email addresses back then tended to start with the country first, then narrow down at each step. Then late 90s a perfectly working system was scrapped, everything was up-ended and email addresses were reversed so that now it would be jsmith123@salford.ac.uk
No: the ! told which was the next machine to send email to via UUCP, the final part was the username. For this to work you needed to know which machines talked to which other machines. At one point I had an A3 sheet above my desk with a world map, 100 odd machine names & lines connecting them.
So your routing path would have looked like: machine1!machine2!jsmith123 ... this is the email address that you gave to the mail or mailx program.
this is the email address that you gave to the mail or mailx program
Yes. And the email address you gave to other people was something like {ucbvax,a-few-other-hosts}!decwrl!marvin!cobb, where you chose a list of well known, well-connected systems as the starting point because other users would know how to reach at least one of those from their own host and those hosts knew how to reach your external gateway (decwrl in this example).
"jsmith123@uk.ac.salford" was a JANET thing, possibly/probably related to one of the X.something communications standards that I can't be bothered trying to search for just now (OK, I lie: searching Wikipedia for "JANET email address" does, as it so often does, The Right Thing: JANET NRS)
I also had an email address at around the same time, and I dimly remember that email to some friends in some places went through in "internet standard" format (TLD last) just fine, but for some other places, you could see in the mail headers the mail going through a relay somewhere that flipped the addresses back and forth to the previous JANET format as necessary.
Bang paths, as in (not quite) jsmith123@uk!ac!salford were something different: they were more of a routing guide for UUCP showing which network nodes a message had to pass through to reach its destination (I only recall seeing them in some people's usenet postings…).
Where would the post code go? Technically, it identifies your house as one of a small set (usually a dozen or so, but I've seen up to 30 on the same post code - one entire side of a street).
From an ordering perspective, it would then be:
Eng(er)land, London, SW1A 2AA, Downing St, 10, The BBB
"How is the ISO format backwards? Or do you think of time in terms of ss:mm:hh ???
Coarse -> Fine is the only sensible way."
Well, right now, where I am, it's just gone twenty-five past twelve, and is nearly half twelve (although that latter can also be rather misleading, depending on which language you are speaking!).
But, yes, that's everyday informal speech, where I might also (but very rarely do) say that it's September the 15th, rather than the 15th of September, so that's perfectly fine and not ambiguous.
In written form, however, ISO format or DD/MM/YYYY all the way.
(It makes me wonder just why the USA puts so much bizarre emphasis on putting the month first. I mean, it's not unusual for any of us, in an insufficiently caffeinated state, to forget what date of the month or day of the week it is, and so need to check, but needing a reminder of what month it is first? You've either had a very long sleep, or are a time traveller (in either case, year might still be a good place to start.))
There are no other very commonly used 'backwards' humanly readable date formats, multiple forward formats. yyyymmdd being the 'most backward' format make it ideal to replace them all, it's logically simple with no room for ambiguity and little risk of confusion with rare alternatives.
As a programmer working with international companies, I have had no end of grief getting data to integrate only to find that, not only there are dates in the US format, but not all dates are in the same format because the file has contributions from a group of people.
That is a can of worms I wouldn't wish on my worst enemy.
I can relate to that. In the very early days of visual studio, the inbuilt date conversion functions had a habit of borking dates with data sent from multiple countries in different formats. So I ended up writing my own functions to handle all date conversions - at least their conversions were consistent without the odd rogue US date format appearing and mucking things up. Similar problems with the opposite use of decimal points and commas in numbers formatted as strings between European countries.
In the very early days of visual studio, the inbuilt date conversion functions had a habit of borking dates
Aaargh! I'd forgotten about that. It wasn't just Visual Studio. The MS run-time library had a function (cdate IIRC) that converted strings to dates. But it ignored the locale and based the conversion on a best-guess - if the leading digits were between 1 and 12, it assumed a US date, otherwise a European date, so "12-01-2000" was the beginning of December, but "13-01-2000" was mid-January.
VB6 silently used this function if you passed a variant or string where a date parameter was expected. Given the indiscipline of VB6 programmers, and the lack of decent analysis tools, it was impossible to eradicate from the code base. In the end I had to create something that patched the function when the run-time was in memory. Ugh!
Yes! That's the one. It completely ignored the locale settings (unbeknown to me at the time) and did its own thing. Caused me some grief. The code seemed to be working fine converting date strings as though they were in UK date format when I wrote it until the beginning of the following month when it decided that the date strings were all in US date format.
So, now that I am reassured that I'm far from the only one having had to deal with this specific bunch of vipers, could someone please explain to me why is it that we are in the 3rd millennium, using object-oriented 4G or even 5G languages, and we are still writing dates as strings ?
Why is it that there is no language today (caveat : that I know of) that treats a date as an object with three parameters and the format it is shown in depends on the OS ?
Is it really that hard ?
(Yes, of course it is, because legacy - but dammit, couldn't we at least get a choice ?)
I find that difficult to believe. If a programming language does not have a proper date object, then I seriously doubt that dates are stored as anything but a string.
Because if dates were somehow magically stored as objects, then writing to a csv file would not have so many different formats.
Usually it's "ticks since epoch".
The tick is usually days, seconds, or milliseconds, and the epoch... varies somewhat (though 1900-01-01 00:00:00.000 is common)
CSV is an undefined text format, so all data re-encoded as such is suspect, always misinterpreted and often mangled beyond recognition.
Hey, less of the attempted minimising, yankee-boy! It's certainly not only Europe that writes or quotes dates in logical hierarchical order.
Don't try to pretend that these are two competing date standards, because they aren't. The whole world uses the logical DD/MM/YYYY format, not only Europe (which is not the the same as EU, use EUR if you really must), with greater or lesser use of ISO 8601 (YYYY-MM-DD) in officialese (and sometimes in personal usage).
The only country that ever thought that a goatse-like "middle first" date format was a good idea is the USA. The rest of the world recoils in horror, and we roll our collective eyes, and reach for the mind bleach.
Note that Date format by country shows the above (date formats in use, not goatse!), there is only one country in MDY red (they're the bad guys, yeah, you taught us that?) and everyone else uses DMY and/or ISO 8601.
FFS. this is just basic failure to communicate. Given the details came from a US org I would be wary with a date stamp anyway....and I would seek clarification in the first instance as to whether they meant A or B. this is easy. not rocket science. this can be done without trying to get a whole country and population mindset to change their ways.
«Sadly lots of Americans think GMT means "UK time", and have no concept of BST (GMT+1) as daylight saving time.»
Sadly there are also quite a few people in the UK who don't distinguish that specific and necessary difference when they really need to as well, and then wonder why their international videoconference calls are an hour out, and there's either nobody at the other end, or they've missed it…
Since I grew up in Europe the 24H system is second nature to me.
After I moved to the USA I figured it was just my European background that caused me to have a hard time with the 12H-system. Until...
1) A colleague showed up for work on Monday, although I thought he was supposed to have flown out to our European office the previous day. "Yes, but I got to the airport at night instead of in the morning."
2) A key server went down in the middle of the day. Somebody had confused am and pm when they created the cron-job.
Of course, the usual complaint was that the 24H-system is just "too hard". So far I've resisted the urge to tell them that my six-year-old niece knows that her favorite TV-show starts at 18 hours...
Wife had afternoon hospital appointment, so we booked a taxi for 2pm.
Was waken up by the taxi driver calling at 2am.... I explained that we had booked it for 2pm, 2 o'clock in the afternoon - 14 hundred hours.
He was very apologetic, not the first time it had happened. My thought is that if you need to go to hospital at 2am, you'll probably need an ambulance!
I knew someone in New Zealand that received a legal nasty gram about downloading illicit content from their dynamic IP address at a particular time. Daylight savings time differences between
NZ and UK mean between April and September NZ is 11 hours ahead and September to April it's 13 hours ahead of the UK. After much investigation we worked out someone got 11 hours ahead mixed up with 11 hours behind, which is probably Hawaii. It took sometime for them to accept this though.
Years ago, running the web infrastructure for a small company, I was asked to go through the web logs looking for entries requesting certain URLs in a specified date and time range. I was told the request was from a national law enforcement organization and not much else. I kept my logs in UTC as I was not going to deal with time changes twice a year screwing up the entries.
My first question was what time zone the specified time range was in. It took several days to get that clarified so I could search appropriately.
They shouldn't be using Excel for handling genomic datasets to begin with. I've had to deal with these many million line datasets after they've been through the Excel mangle and it isn't a pretty sight. Not only were the names of a select portion of genes mushed into dates, the scientist had copied and pasted the standard deviation column into the right column but shifted down by 5 rows replicating a whole set of values, managed to include zero values in the mean calculation (failed reads from the plate reader), and copied and pasted a subset of other values into the wrong block.
It's only when I instead on having their raw data direct from the machine as well as their Excel summary that these errors were picked up - the paper was written, checked, double checked, triple checked, reviewed, checked again and was about to be published when the "web accessible" version of their dataset was asked of from me. It was pure bloody mindedness on my part that I decided to redo all the descriptive statistics on the fly instead of using stored values that meant I picked this up. Excel is a pile of spread sheet for most tasks, and I just don't get why people seem to like it so much and force it to do tasks that there are far, far better ways of doing. I mean... arranging shift patterns FFS - use a calendar! Lists of students and fees paid shared between administrators - use a database! Spreadsheets are good for a quick one off rough guess at something involving numbers. If you have to repeat something, write a program to do it, store it in a database, anything that means a slip of the mouse doesn't have the capability to introduce a fatal error.
So we relicence the Yanks to
10/10/2020 or 11/11/2020 and so on.
Needs to be 100% compatible with the proper software so we can use it in our office.
I did insist on YYYY-MM-DD for their acounts link.
But inches - aghhhhhhhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!!!!
They get stored by an algorythm converting to nearest mm and back again, IN THE FIELD EDIT.
It's ages since I looked at an RS catalogue but they insisted on giving dimensions for components based on converting a 1/10th inch grid to metric. Spaces between pin positions on ICs being specified down to the diameter of a pollen grain? Really?
The Spanish Police, especially the Guardia Civil (Civil by name but usually not by nature) must have frightened the living daylights out of the innocent people. The suspicion and probably rumours or rumors if you prefer. Their life will have been made a complete misery. Money is little comfort when faced with such an injustice.
(Apologies if you've read this anecdote here before)
My yank boss agreed to take us from the Netherlands to Scotland for the MS Exchange course. He asked me to pick him up at half eight, but was furious when I picked him up at half eight because he'd been waiting for an hour.
In Dutch half eight means 7:30am/pm. He assumed that was all of Europe. In the UK half eight is always 8:30.
He was also angry when I drove him to the Scottish Claymores shop. He assumed it was a shop that sold swords, it was a shop that sold merchandise for the Edinburgh "American Football" team. Then he got angrier when I couldn't drive him to a place that sold swords. We're kind of banned from buying swords since 1745.
In retrospect I don't think he liked me. He was a huge, rotund fellow who boasted his size meant he could maintain a constant internal temperature, but he couldn't maintain his temper.
"Police scoured mobile devices and took away a computer that the family eventually recovered through the help of an attorney."
See, here's the part that always boils my... urine. If the family were found innocent it should have been automatically returned. Why did they have to have the added cost of an attorney?
As a Canadian, I would like the Americans, and their British lackeys, to stop mispronouncing the word for KM. as Kill-Ommiter, as though it's some sort of speedometer or tachometer.
The word is pronounced KILOMETRE as we were taught in Canadian schools so many decades ago. And most Canadians pronounce it correctly.
Recently I even heard news announcers on FRANCE24 pronounce it incorrectly! Migod, the French INVENTED the Kilometre!
Steer clear of the internet until the 13th of the month, unless it's the 1st Jan, 2nd Feb, 3rd Mar, 4th Apr, etc.
There's also a potential ambiguity with time zones and daylight saving time, too.
===
Another possibility for Month that people used to use is Roman Numerals e.g, 22/VIII/2021
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
