Call me a snob, but...
"Yup they was like a set you get 2 burgers 2 buns 2 cheeses slices and a sachet of the relish ."
That food sounds so processed it would probably last forever...
Date formatting is one of the many banes of a programmer's existence. Pity, therefore, the Tesco customer presented with a date in the Julian format. Many developers experience a slight eyelid twitch when date formatting comes up. For sport, try mocking a greybeard about the two digits used to describe the year in older …
According to an interesting programme on food safety a few years ago (possibly BBC), expiration dates are set by measuring how long it takes from contamination until the food is unsafe to eat. The premise is if it somehow gets contaminated before leaving the factory it shouldn't kill anyone.
The food, including fruits; was exposed to strong UV light to kill the bacteria.
Since UV is a radiation type, and the emitter could cause some minor harm to humans if exposed long enough, HSE meant a radiation warning sticker on the machine.
Radiation sticker = NUCLEAR POWER to the brain dead, and so the hysteria started.
I am still amazed CD players made it, as the laser is also a radiation source, so there is a similar (if smaller) sticker on all CD/DVD players.
I've got a pain all the way down the left side of my calendar.
I've just been having (very limited) amounts of fun with a customer, who have a system maintained by a third-party supplier.
Said supplier seems to have extremely limited technical capabilities.
First, they complained about the fact that we use the date format "YYYY-MM-DD" for data import/exports, and asked if we'd be willing to change to DD/MM/YYYY. So I politely explained that this would be a bad idea, as there's a risk that it'll get confused for MM/DD/YYYY.
Then, we came to the CSV file that's going to be delivered as part of the process. Things were already a bit strange as they wanted it pipe-delimited rather than comma delimited, but things took an even stranger turn when they flagged up the fact that only some fields were quoted.
Cue an even politer explanation about the fact that we're using the standard platform CSV exporter, and it doesn't quote fields unless it needs to. And I pointed at the CSV RFC, which explicitly states that fields only need to be quoted if they contain certain characters.
"Oh, it's ok", they eventually exclaimed. "We'll just delete any double-quotes from each line before we process it. And as we asked, you're sending the file with pipe delimiters, so we don't need to worry about escaping commas".
It's rare for me to be literally speechless, but it did take several seconds before I felt safe to respond...
*Hands you a pint & taps brims in toast*
Here's to using the proper YYYY.MM.DD format.
It auto sorts itself properly, it's hard to get the digits mixed up, & it makes everything easier.
Everyone whom uses a different format is an utter poopyhead. =-)P
MONTH-DD-YYYY begs to differ on all points save computer auto-sortability. But changing your filing system to suit your computers is rather like changing the postal service area to make another post office handle it because the postal carrier's walking too far, rather than, say, hiring additional carriers.
There must be something about Americans that makes them want to deliberately do things the arse-backwards way. See also: using non-metric units long after the rest of the world has moved on, insisting that a constitution from two hundred years ago is still perfectly attuned for modern life, etc.
The most frustrating thing about the American's use of the imperial system is them not using all of it.
One of the important points of the imperial system is there a unit bigger or smaller that you can go to if the numbers start getting too big or small. Take length, you start at inches, then move on to feet, yards, chains and miles. With weight you have ounces, pounds, stone, hundred weight and tons.
So why do they insist on specifying the weight of a car or locomotive in pounds?!
"So why do they insist on specifying the weight of a car or locomotive in pounds?!"
Because deep down they know that they really want to use kilograms like proper grown-ups, but are just too scared to admit it to some of the MAGA-hat-wearing types out there?
(Arguably none of us gets it quite right: we perhaps ought to use Mg for quite heavy\\\\\massive things , and Mm for distances on the far side of the Earth, but we never do!)
 Quite heavy, as in the order of magnitude of 1 m³ of water (that always amuses me to think of, but I'd much rather that didn't fall on my head all at once).
Nah. The fellow likely works in the publishing industry (newsprint), so they are converting from whatever SQL DB to Progress OpenEdge. Leaving the vendor name out because it changes every three years anyway. It uses a modified 4GL they call ABL (Advanced Business Language or some such). And they love that pipe separator, just like Informix. That said, the record (line) separator can be specified as either a pure LF or CR+LF combo, instead of ending with a pipe + LF.
Fun fact about Progress databases - the data fields are not fixed. If the table definition says that this particular field is up to 27 characters, but you want to put 34 characters in there - Just Do It! However, you'll have to remember to tell Progress that the field is now longer, otherwise some of your data will not show for you.
I had a client about Y2K time in printing. They too used an application that used Progress IIRC. Can't remember the vendor name. Another client, same industry, also had an industry-specific application that did use Informix on SCO. From the perspective of most sales and stock operations they do things a bit peculiarly there. The Informix based one had an interesting quirk. They were, I think, supposed to ship with a run-time only installation but they had ?accidentally left in one of the development applications - sformbuld IIRC. But as all the non-4GL development applications are all the same executable, just link to the relevant names and, ooh, look, a full Informix development suit.
> platform CSV exporter
Errr.... which platform? Almost every CSV exporter is custom build.
Also note, "the CSV RFC" is not as clear cut as you're making it out to be.
It was only an attempt to draw a sand in the line as there were so many incompatible implementations already floating around.
That RFC does cover most of the common stuff, but doesn't cover a few key areas (null values? binary encoding? unicode bom? field names?).
There have been some follow up concept docs started since, but nothing has become a new & improved RFC yet either.
The commata... Great fun in countries that use it as a decimal separator. The Tektronix oscilloscope we had in our lab could export to csv files, (well, some windows program talking to it over USB could), but would use the locale to choose a decimal separator. Hilarious. Not. (at that time).
"The commata... Great fun in countries that use it as a decimal separator."
Altenatively there's the double take when getting a hotel bill after a 10-day business trip in India before you remember that they add commas at thousands and 100-thousands ("lahkts") so the total with two commas is actually 10x smaller than your mind has initially registetered!
Techtronix is in good company: Labview, a 'systems engineering software' commonly used for the control of scientific equipment takes the locale from the host computer to choose the decimal separator. In a place like Germany, half of the computers will become incompatible with your carefully grown jumble of data acquisition and analysis programs, simply because you have a mix of German and English locales in the academic environment.
Just one of the many nightmares caused by those greedy bastards at National Instruments / Labview.
Keysight (HP rebranded) now use comma separators between all elements of both date and time returned by their measurement gear. As these instruments comply with SCPI (which uses commas to separate multiple readings returned from a single command) this renders it impossible to use the data and time stamps in CSV output.
> Errr.... which platform? Almost every CSV exporter is custom build.
For better or worse, ours is pretty much a straight call to PHP's built-in library (which effectively boils down to "fputcsv(fp, array)").
Language-haters incoming in 3... 2... 1...
> Also note, "the CSV RFC" is not as clear cut as you're making it out to be.
This is true. The RFC is an attempt to formalise something which is very loosely defined and prone to abuse/hacks. There's no shortage of implementations where someone's just jammed a comma between the fields in each line and hoped for the best.
But at the same time, we're generating the file using an industry standard implementation which has been tried and tested by millions across the world.
And from the conversations we had around transmitting the data in other formats (e.g. JSON, XML), I strongly get the impression that whatever the solution would have been, they would have manually hacked a parser together to brute-force extract the fields.
From this, the two main scenarios are that they're either running on some hideously restricted platform, or that their technical capabilities are seriously lacking. Or possibly both...
> But at the same time, we're generating the file using an industry standard implementation which has been tried and tested by millions across the world.
*cough*. MS would make the same claim for their software (Excel output, etc). And probably be just as accurate, yet just as incompatible with other implementations. ;)
... "Oh, it's ok", they eventually exclaimed. "We'll just delete any double-quotes from each line before we process it. And as we asked, you're sending the file with pipe delimiters, so we don't need to worry about escaping commas".
This story resonates with my own experience. Things like this seem to be increasingly common. I've gone past getting mad, now it just makes me sad...
no address will ever contain a pipe character
Ooh, ooh, ooh - sounds like a challenge!
My hobby is now going to be inserting a | at the end of my house name every time I type it into a web site. I wonder how many will accept it? And how long before it starts appearing in address databases?
I remember dealing with a data analyst at a major insurance company. Having been asked for a CSV, he sent me an Excel spreadsheet (.xls format). On being reminded, he sent me a .csv. Oddly enough, this failed to load, and when I looked at the file in a text editor it became apparent that what the "analyst" had done was change the file extension of the original spreadsheet. I had a bit of a pause before responding, mainly to work out how I was going to start the ensuing conversation.
Well done indeed. Groanworthy in a good way. How did someone with a sense of humour get into corporate PR, and what kind of Red Tape let it through? Congratulations to Tesco for allowing that through without at the same time subjecting the world to a full Bozzersworth of toecurling gaffes.
… this is why we have things like norms (BSI/EN) to which you can point the supplier and say: "like that". Imagine all the fun you can have with unlimited liability if something like this went stateside, someone consumes said product unable to understand the best before date and sues over food-poisoning. Actually, I bet this has already been tried. Many times. Many, many times.
Of course, what's slightly worrying is that the ISO spec is behind a paywall. Though not quite as worrying as that the supplier maybe running a computer system so old that it needs to save the odd byte!
I think we should be getting ready to accept the equivalence of less/fewer. It's certainly not high up on my list of pedantic peeves:
It has nothing to do with the subject being plural, it's whether it can be counted as in discrete individual items or has to be measured as in a quantity.
Fewer people, less time. Fewer problems, less fun. Exactly equivalent to "number of" and "amount of".
I do understand the difference and can use them both correctly. But my "internal parser" doesn't seem to care that much when I hear or read them used incorrectly (less seems invariably to replace fewer), after all we don't see to care when talking about more of some thing. This might have something to do with that the distinction isn't made in the other languages I speak.
Like I said, there are other linguistic trends that I fight more objectionable. But each to their own.
To be honest, it's not really high on my list of pet peeves, either. It's not the level of illiteracy that inclines me to dismiss a poster as hard-of-thinking.
I just couldn't resist applying the Tesco slogan to a post about saving a digit. Having done so, how could I not then also bemoan the saving of a single letter in a grammatical error which might, in the humorous context, have been entirely intentional? Elsewhere in this thread, I pose a question to which I know the answer perfectly well, only to see it explained to me (I expect it would be called "mansplaining" if the posters katrinab and myself had been reversed).
The less / fewer thing is all very well, but where's the opposite gone? We're already using more for both jobs - and have the saying "more or less". But there's no more or fewer...
Which leads me to the opinion that fewer is pointless. Why do we have this distinction, and does losing it lead to ambiguity? After all, we say more people, more time more problems, more fun.
"Imagine all the fun you can have with unlimited liability if something like this went stateside, someone consumes said product unable to understand the best before date and sues over food-poisoning. Actually, I bet this has already been tried. Many times. Many, many times."
Tesco do make the point that this date is purely a manufactures internal checking system on packet inside the main packaging and that the Best Before date intended for the customer is printed on the outer packaging exactly where it's legally supposed to be. I don't think there is a requirement for a Best Before date on individual packets within these "meal kits" because the outer packaging must have the Best Before date for the shortest lived ingredient/item.
Over here in Canada, it is very common to still see packing dates with a 2 digit year.
Anyone who has spent much time with databases and import/export of data knows what a complete headache date formats are.
Adding Julian dates to that unholy mixture is just taking the p*ss.
The point is that a 2 digit year makes the format ambiguous.
Knowing what the year is, is not the point.
But if you can't determine the format of the date unambiguously, you can't know which is the day and which is the month reliably.
Since the year is 2018, then assuming that you know the can of food was bought this year, then you can probably determine that 18 is the year part. However, canned food can have a very long life indeed.
For the cost of just putting an extra couple of digits for the year, that ambiguity is reduced immensely.
YYYYMMDD is allowed by ISO 8601, and has the pleasant property of numerical sort order being the same as date sort order. Although the hyphenated format YYYY-MM-DD is more agreeable to people and still lexically sortable until 10k AD rolls around.
What I hadn't taken note of previously is that ISO 8601 also includes an ordinal date representation, YYYY-DDD. (Must be three digits, otherwise it would be ambiguous with YYYY-MM.)
That ordinal date representation probably causes problems during leap years. I wonder how many systems assume DDD <= 365 because the programmer didn't consider that. Plus while I imagine the ISO standard specifies it, and I assume Jan. 1 is 001, there's room for ambiguity there as well if the programmer doesn't have that ISO standard in hand...
One of the drivers behind ISO8601 formats such as YYYY-MM-DD and YYYY-DDD is that they are precisely defined in the standard and not in prior use. So they are fairly unambiguous. Users of the formats will know that MM ranges from 01 to 12 and DDD from 001 to 366.
Hehe, good to know that Markus Kuhn's website is still around. He's one of the names I recognise from usenet, umm, mumble, years ago...
(Funny/sad how not so many names from usenet necessarily seem to have transferred to other social networks, assuming similar ongoing interests, although I think there are a couple of names here in The Register comments that I recognise. (Of course, many of us, then and now, go under at least semi-pseudonyms...))
Ah - standard VMS Date/Time format. The best way to handle dates. Completely unambiguous.
(And before people start on about alpha sorts, most of the time my dates are in a database, in a date/time datatype. The only time you need to do an alpha sort is when you express the date outside the datatype (like embedding it in file names, for example))
When I worked for the London office of a US company, I always wrote dates in documents and emails as dd-mmm-yyyy. So today is 26-Jun-2019.
But for databases, 20190626 is much better.
Excel stores dates as integers, but displays them as dates, if you mark the cell as date format. So 20140 becomes 20/02/1955. The Tesco claim of Julian date is nonsense: a Julian date is a pure integer, not some combination of year and day-number.
From the Internet, so it must be true:
What is Julian date example?
A Julian date is sometimes used to refer to a date format that is a combination of the current year and the number of days since the beginning of the year. For example, January 1, 2007 is represented as 2007001 and December 31, 2007 is represented as 2007365.
No, it's worse than that. https://en.wikipedia.org/wiki/Julian_day
"The Julian day number is based on the Julian Period proposed by Joseph Scaliger, a classical scholar, in 1583, at the time of the Gregorian calendar reform, as it is the least common multiple of three calendar cycles used with the Julian calendar:
" 15 (indiction cycle) × 19 (Metonic cycle) × 28 (Solar cycle) = 7980 years"
So it can mean either the number of days since the epoch (to astronomers and historians) or the number of the day in the year (to people who make ready meals).
So it seems Julian date != Julian day != Julian calendar. Here I was happy in my ignorance that the Julian calendar ended in the 16th-18th century depending on the country.
Yes, my eye has started to twitch, as has other parts of the body, but that started happening years ago such is IT.
"There's a reason that the anniversary of the October Revolution of 1917 is in November."
Also why the UK tax/financial year starts on April 6.
... origanally years started on March 25 (Lady day - still used for many agricultural rent payments) because the year was "Anno Domini" - i.e. years marked by the presence of Jesus on earth - and if he was born on Dec 25 then he was "present in utero" 9 months earlier on March 25). When the UK switched from Julian to Gregorian calendars (due to the drift in seasons until the Gregorian calendar introduced the additional leap year corrections every 100 and 400 years) which resulted in 11 days being dropped from the calendar to correct dates led to popular revolt over the idea that the government were doing it to get taxes earlier meant that the date of taxes being due was moved back by 11 days - hence the oddity of April 5/6 is the boundary of UK taxes years.
N.b. for IT angle ... I remember talking to someone who worked for a big software house when they were starting to considere Y2K issues and when they thought they'd got this all under control someone raised an issue that "isn't there something special about leap years when the year is divisible by 100" as no-one had considered this .... fortunately the rule drops leap years when the year is divisible by 100 unless it is also divisble by 400 ... so 2000 was still a leap year.
The Julian calendar reform didn't add any months; there were already 12 by the time that Julius Caesar changed the calendar. Arguably they removed one, since an intercalary month was removed. The reason for the numbering of the second half of Roman month names being apparently regular but out of whack (Quintilis, Sextilis, Sept through to Dec- ember) isn't really known. Later Romans believed there were originally only ten, their supposed "calendar of Romulus" lacks January and February, but modern historians doubt it, there may never have been ten. For a while those two months were at the end of the year and probably moved to the start about 100 years before Julius.
By the time of the Julian reform the Roman calendar was mad. Between 355 and 378 days in a year, depending on the decrees of the pontifices (there's a reason the term sounds familiar), a decision theoretically made to keep the seasons in line, but usually practically made to influence political terms of office. Is it the nones, the ides or the kalends of the month?
https://en.wikipedia.org/wiki/Julian_calendar is a fascinating insight into classical era astronomy, politics and international relations with a bit of date accounting tossed in on top. But anyone who thinks DD/MM/YYYY versus MM/DD/YYYY is an eldritch horror had better not read it.
You're not wrong. Section 1.252 of the Explanatory Supplement to the Astronomical Almanac defines a Julian Date to be a Julian Day Number plus a fractional time of day; e.g. 20145.5. Even, Meeus, bless his cotton socks, grudgingly admits 'In many books we read "Julian Date" instead of Julian Day.'
If you'd asked me before I'd read this. I'd've said it was either a count of terrestrial rotations from the Julian epoch or a calendar date expressed in the Julian calendar. But the adjective Julian gets liberally used in astronomy.
Reminds me of that scene of Indy almost falling to his death due to ambiguities related to the spelling of the name of God. I can kinda imagine an alternate scene where dates are involved instead, and upon realising this Indy flat out goes "oh HELL no, screw this!" turns around and just walks out...
Thanks, I wondered where this aberrant version came from. Probably best not to even mention Modified Julian Date. It is a very large number of days and half a day out from the original Julian Date. I think some people may be using MJD but calling it Julian Date.
All very satisfying - if you are not a professional programmer.
Best before dates are only useful to the supermarkets as a way of ensuring they get rid of their old stock first so it makes sense for them to use a code that is not meant for the consumer. For a consumer a best before date is misleading and can cause people to throw away food that is perfectly edible because the best before date has been reached and really should be removed from packaging.
A use by date is different and should be adhered to more strictly, although with a bit of common sense food can still be eaten passed its use by date. Give it a visual and smell check first to see if there is any signs of it going bad. After all the human race has managed for millennia without pre-packed food with best before and use by dates on it, without everyone getting food poisoning.
Quite. And while poking fun at supermarket procedures is fun and all, it's worth noting that the manufacturing code on integrated circuits and the line often uses a year-week or week-year format.
In test applications (particular military tests), we often use ordinal/Julian dates because tests often run across day boundaries but rarely across multiple year boundaries, and who wants to fuss with how many days February has?
In fact, IRIG-200 (defining IRIG-B, etc) uses the phrase "time of year" to refer to formats having a day component. And it's typically encoded in BCD, so standard-issue humans can see at a glance what the timestamps represent.
However, that's on the slow way out, being replaced by the IEEE 1588 format, which is its own level of pain as it's a tuple of (seconds since epoch, nanoseconds), usually encoded as a pair of unsigned integers, with the seconds supposedly a 48 bit quantity (nanoseconds is 32 bit). OBVIOUSLY people muck around with this, making the seconds signed and 32 bit if it suits them, because why not!
This episode has jogged a memory from last year, when Tesco did rather less well on dates and twitter.
Cast your mind back to 1st March 2018; this was the last day that paper £10 Bank of England notes could be used. Having a small amount of cash at home for emergencies I realised it needed to be spent. So, that afternoon used it to top up a travel card and attempted to buy some groceries. You can see where this is going. Tesco metro staff adamant that "no longer used after 1st March" means no longer used on 1st March. So I went and spent the money at Sainsbury's instead.
Slightly irritated (and after checking) I complained on Twitter, and rather than pickle puns got an un-amusing, "As of that date, they are being withdrawn from circulation. All our colleagues at manned checkouts are aware that they should not accept the notes from 1 March." It appears the entire company misunderstood the BoE guidance and stopped taking them a day early.
Of course "legal tender" is a strictly limited concept, and shops can choose not to accept currency pretty much arbitrarily; it's why your local corner shop is in its rights to put up "No £50 note's" signs. But I thought it was a bit poor that a. their twitter team couldn't simply say "sorry about that", b. whoever they put in charge of the phase-out failed to check the most basic thing about their task. Fortunately one of the up-sides of living in a fairly big city is having some choice over the level, or at least type, of muppetry you'll tolerate, so I haven't given them any plastic £10 notes, or indeed money in any other form since.
"Of course "legal tender" is a strictly limited concept, and shops can choose not to accept currency pretty much arbitrarily; it's why your local corner shop is in its rights to put up "No £50 note's" signs."
If they haven't given you the goods beforehand they can stipulate any method of payment at all, including chickens (as long as they have a GBP equivalent for VAT reasons). They can also decline right up until the payment has been accepted. They also don't need to provide change, which is how vending machines get away with it.
If you already have the goods, then they cannot refuse to accept £1 coins, but again don't have to give change. They can in theory decline any other method, but you can often get a debt discharged if you can prove they have refused reasonable methods of payment.
Think this one might be lawyer territory. While it seems to be the case that with petrol you are settling a debt (as the goods have already been supplied, though if not you could do a little dance of having payment refused and then filling out whatever inability to pay form they have to create a debt), there is mixed advice about when legal tender actually settles a debt. Bank of England and the Royal Mint slightly differ ("pays into court"), with this heroic freedom of information request eventually getting the response that they should seek legal advice. And at the end of the day you are dealing with someone who doesn't really know the law either and is just doing what their manager told them.
> "since much of the US insists on the barking mad month/day/year format,"
What's so barking mad about it? If it made sense, half the programmers in the USA would be unemployed! Half of the code in my programs end up being convoluted day/date conversion routines. Viva la madness!!
convoluted day/date conversion routines
Also true for the mere scripting languages. Try converting to proper dates when the US date formats have already had Excel or Access run their helpful eyes over them ("12/1/2018"? Oh that's easy - it's the 12th Jan. "5/22/2018"? no idea - let's leave it as text. "11/22"? OK, that'd be 0.5. No worries - happy to help)
There are people working in the US who I've never met, but their names are writ high on my ToDo death list.
I feel inundated if not intimidated by all these date formats. Many of them predate / antedate the modern era, so why shouldn't we just invalidate a whole bunch of them, consolidate the remainder, select a very few as candidates that accommodate the most widespread current usage, elucidate which of this small subset gains widespread adoption, and mandate its usage?
It would make life much more sedate.
Just because a major US motoring manufacturer insists on the bloody format.
To make it even more confusing try matching up our system (week numbers) with this.
So this year week one started on 18365 and week two 19006.
It's even more confusing as the years move on and the dates get more skewed.
I used to work for a company that stored dates in its product database as the number of days since the 1st of January 1901. When I asked why, I was told "because" and given all the crappy jobs as an incentive to never ask again. Since I left I've been informed that they now use SQL Date format. The American M-D-Y date system is stupid, as is the Kazakh Y-D-M, the European D-M-Y date system is only marginally less stupid. Only the ISO date system of YYYY-MM-DD HH:MM.SS.mmm.uuu.nnn.ppp.fff.aaa makes any sense at all, although basing it on the the birth date of one particular person is also pretty stupid.
However, it's all a human invention so it's bound to be a neurotic f***ed up mess of a system.
This line from ISO 8601 made my eye twitch just a wee little bit:
"Note 2 to entry: In IEC 60050-113:2011, 113-01-03, time according to the space-time model is defined to be the one-dimensional subspace of space-time, locally orthogonal to space."
Are these ISO guys from the Committee for Real Time perhaps?
I've noticed that Amazon is putting things into its Australian catalogue with MMDDYYYY dates but interpreting them as DDMMYYYY, so products that are actually available now are not available for another |MM-DD| months.
Of course if you try to tell one of the Amazon support droids, then they just suggest something like you reinstall your browser. ( I reported spelling errors in the Kindle Android app user interface and I was told to reinstall the app....) . What was it that Jeff Bezos said about making three good decisions per day??? I hope they balance out the millions of bad decisions made as a result of his one decision to remove thought processes from his product support.