If Denis Norden didn't need to censor 'cockups', I don't think The Reg has to.
Developer’s code worked, but not in the right century
Why hello there Monday! And hello, therefore, to a new instalment of “Who, me?”, The Register’s column in which readers confess to their c*ckups. This week meet “Lars” who told us he once worked for “a large outsourcing company” that assigned him to do some work on a major supermarket chain’s loyalty card program. One of the …
COMMENTS
-
-
Monday 18th June 2018 07:33 GMT HPCJohn
Can someone explain to me ... why in the blue blazes would a supermarket have its own date format? I guess a database expert can explain.
But more importantly why is a format like that not documented and given to all developers?
I know it is not a comparable situation, but I have a great respect for ISO 9001 standards for documents. ISO standards might seem boring in the extreme. However there as a case of a person receiving a radiation overdose because the dose calculation was performed using a superseded document. Far more serious than loyalty points.
-
-
-
Monday 18th June 2018 17:23 GMT Mark 85
Re: Re : Can someone explain to me...
"Why this wasn't tested offline first before applying it to a LIVE database ?"
No test database?
That wasn't uncommon. Been there, done that and screwed up the "live" data base once... lesson learned. I didn't start seeing test databases until around 2000 due to the costs involved for storage, etc. In at least one case, it was the IT manager who felt that programmers were perfect and thus no need for one.
-
-
Monday 18th June 2018 19:02 GMT Anonymous Coward
Re: Re : Can someone explain to me...
> You think there's a test database when they did bit fiddling with the date format to save space?
A test database for the task at hand could be as small as one or two partial records, if need be.
That said, I am not criticising the person in question as I do not know the whole story.
-
-
-
Monday 18th June 2018 08:23 GMT H in The Hague
"... ISO standards might seem boring in the extreme."
I've now reached the age where I consider that far preferable to the wrong kind of excitement.
(Anyway, those standards mostly say: think about what you're doing, do it consistently, and make sure you can prove it - common sense really.)
-
Monday 18th June 2018 10:53 GMT Doctor Syntax
"those standards mostly say: think about what you're doing, do it consistently"
I'm not sure low level customer service agents are allowed to think what they're doing but consistency seems to matter, even if it's done badly. Once something goes wrong any complaint leads to the same wrong being repeated.
Newspapers often have a weekly column where a journalist manages to sort out various customer issues with big companies. Inevitably the problem has gone round a C/S loop several times without success, gets fixed as soon as it gets tackled out of loop and turns out to be some combination of "unique" and "computer" issue. The only thing unique was that it got handled by the company's press desk who needed a sensible answer. Up to then it had probably been handled strictly according to the C/S scripts with all the consistency that ISO 9000 and the like dictate. A few decades back the talk was of "empowering" C/S. That's been killed in the name of consistency.
-
-
-
Monday 18th June 2018 08:38 GMT Mage
Re: The Standard Date Format?
I do like YYYY MM DD HH MM SS. Not sure what the standard way to store is. The US printed format MM DD YYYY is a broken idea.
XKCD Standards
I think year 0 on computers should have been end of last Ice age in Ireland, or date of founding of first town in the world.
Two sizes of date / time object?
Big: Heat death of Universe with resolution of Planck time
Regular: Expected death of Earth due to Sun + 10 million years, resolution 1 millisecond.
Yes I know 2 digit year was to save storage and existing start dates are compromises. Many/most run out in less than possible existence of human species.
Three main issues:
Start date of storage
Format(s) of storage
Human readable formats, not just in Latin script, but all languages.
-
Monday 18th June 2018 11:24 GMT Mystereed
Re: The Standard Date Format?
"I do like YYYY MM DD HH MM SS. "
We had a bug in a script which did a very similar thing to what you did (and a very easy mistake for humans to make) - the log file showed all updates at 7 minutes past the hour, none for any other minute.
It was July - We needed to use MI instead of MM for the minutes mask :-)
-
Monday 18th June 2018 15:16 GMT jelabarre59
Re: The Standard Date Format?
Yes I know 2 digit year was to save storage and existing start dates are compromises. Many/most run out in less than possible existence of human species.
I had heard some systems in the 1960's had been programmed with *one* digit years. So there were a handful of cases of a "Year 1970 Bug". It should have been a clue that the problem might crop up again.
And as I remember, Business Basic used a *2-character* (not 2-digit) format for years, so you'd have to use a conversion table to manipulate it in outside code. Not that MAS90 was very friendly with outside-code (was a nightmare dealing with EDI and MAS90).
-
Monday 18th June 2018 09:16 GMT Stoneshop
What is The Standard Date Format?
Way back, when harddisks were Fscking Expensive, I inherited a record[0] catalog database for a library, written in Turbo Pascal. To save space on its very minimal 20MB harddisk, dates were coded as 5 bits day, 4 bits month, and 7 bits year counting from 1900, stored in a 16-bit word. That wasn't too bad, since the only date info used at that point were the date of purchase and maybe a date of retirement of the physical item. However, soon after I took over maintenance we decided to also use the database for recording transactions as well. For this a larger PC was acquired for the princely sum of a tick over Dfl.10000, with a 80MB disk, so space became less of a issue. As the database layout had to change anyway, I decided to store dates as Julian making it a no-brainer to calculate date differences (which one could consider somewhat crucial for a library).
[0] the vinyl and CD sort.
-
-
Monday 18th June 2018 09:42 GMT Hans 1
timestamp is a date format
@Katrinab
1. Nope, those are timestamps! They are usually [milli]seconds since, NOT days.
2. 2nd January 1904? (Mac) ? That was up until Mac OS 9 (aka 2000), Mac OS X and macOS use UNIX timestamps.
Maybe The Register can come up with its own special timestamp ? Milliseconds since el'Reg started ?
A date format is, for example, [joke]dd/MM/yyyy in the civilized and MM/dd/yyyy in the uncivilized world. Some heretics also like to use dd.MM.yyyy. l33ts use yyyyMMdd.[/joke]
-
Monday 18th June 2018 18:44 GMT Stoneshop
Re: timestamp is a date format
Maybe The Register can come up with its own special timestamp ? Milliseconds since el'Reg started ?
Sheepmarathons (the time required for a sheep at maximum velocity in vacuum to finish a marathon) (straight line, I expect it'll have some problems cornering at that speed).
That's 0.0070383633 seconds, to be exact.
-
Monday 18th June 2018 10:21 GMT Jonathan Richards 1
No standard for epochs - @katrinab
Those are epochs: the arbitrarily chosen t=0 point for the counter. Formats are the expression of dates in one's chosen calendar.
PS. In fact, Unix counts seconds since the epoch, hence the approaching Unix Time "Apocalypse".
-
Monday 18th June 2018 11:22 GMT Doctor Syntax
Re: No standard for epochs - @katrinab
Unix counts seconds since the epoch, hence the approaching Unix Time "Apocalypse"
From then link: "On January 19, 2038 03:14:08 GMT all computers that still use 32 bit Unix Time will overflow."
In 20 years time will there be anything outside of museums still using 32-bit Unix time?
-
Monday 18th June 2018 13:44 GMT David Nash
Re: No standard for epochs - @katrinab
"will there be anything outside of museums still using 32-bit Unix time?"
Of course there will. Some will be embedded or control systems built by suppliers who no longer exist. Those will be the big problems, because the users won't even be aware that a problem is coming.
-
Tuesday 19th June 2018 06:14 GMT onefang
Re: No standard for epochs - @katrinab
"In 20 years time will there be anything outside of museums still using 32-bit Unix time?"
In 20 years time I would not be surprised that a certain embedded 32 bit device I'm responsible for is still in use. In 19 years time, remind me to bring that up with the client.
-
Tuesday 19th June 2018 06:56 GMT druck
Re: No standard for epochs - @katrinab
Doctor Syntax wrote:
From then link: "On January 19, 2038 03:14:08 GMT all computers that still use 32 bit Unix Time will overflow."
Well it overflows a signed 32 bit number, which will affect a lot of incorrectly written software, but it will be another 68 years before it overflows an unsigned 32 bit number, and really is at the end of the road.
-
Monday 18th June 2018 16:53 GMT Antron Argaiv
Re: No standard for epochs - @katrinab
Unix counts seconds since the epoch, hence the approaching Unix Time "Apocalypse".
[Somewhere in a dusty corner of an otherwise deserted computer lab, two bearded men are hunched over a Teletype]
Ken: Date and time, what's it going to be?
Dennis: Some very large number, so that when it overflows, we won't be around.
Ken: UINT16?
Dennis: Better make it UINT32, that should be fine.
Ken: Right. That should be safe. By the time it rolls over, no one will ever remember UNIX.
-
-
-
Monday 18th June 2018 08:34 GMT Peter Prof Fox
Because computer dates are numbers but real dates aren't
Not yet. Unknown. Since before we started counting. And so on.
When did you move into your house? Come on! Come on! YYYY-MM-DD all the bits! I can only remember it was summer 1989. So 1989 is a perfectly valid real world date which isn't 1st Jan 1989.
Then you need to do sorting and calculations. What is 31st January plus one month? Does 4th August come 'before' or 'after' August? (Neither it is 'in'.) Nobody is sure when Chaucer was born (Roughly 1343) so do we use 'unknown' or wing-it with 1343. J.K. Rowling was born 31 July 1965 so that's fine but what goes in the died field? 'Not yet' which is different from 'unknown'.
More at http://vulpeculox.net/day/
-
Monday 18th June 2018 11:07 GMT Doctor Syntax
Re: Because computer dates are numbers but real dates aren't
Get into historical dates and you have more complications. Julian or Gregorian? Different countries switched at different times and the start of the year isn't necessarily the first of January. (Unix cal always starts with January. man cal, at least back in V7 days, listed that as a bug.)
Then you get documents with the year given as regnal years and/or the rest of the date relative to a church feast or saint's day. Such documents may relate to property.
-
Monday 18th June 2018 15:42 GMT Daedalus
Re: Because computer dates are numbers but real dates aren't
Julian or Gregorian?
You're confusing the Julian calendar with the Julian Day. The calendar is extinct, but the Julian day is used in various settings as a date that is the same across all calendars.
https://en.wikipedia.org/wiki/Julian_day
-
Monday 18th June 2018 19:48 GMT Doctor Syntax
Re: Because computer dates are numbers but real dates aren't
"You're confusing the Julian calendar with the Julian Day."
Oh no I'm not.
"The calendar is extinct"
Not if you're dealing with historical material. Just because you don't it doesn't mean that nobody else does. It's building in assumptions like that that lead to failures.
If you have a Unix-like system with TZ set to one of those for "England and its colonies" (to quote the original man entry) run
cal 1752
-
-
Wednesday 20th June 2018 20:37 GMT Jonathan Richards 1
Re: Because computer dates are numbers but real dates aren't
> cal 1752
[imagine a September where Wed 2 is followed by Thu 14]*
Really, that should be dependent on i10n; different countries switched from Julian to Gregorian calendars at different points in time (and hence with different adjustment days omitted). 1752 was the year Britain and its colonies got on board. Turkey held out until 1926.
*You have to imagine, because El Reg, he no let me paste monospaced typeface.
-
-
Tuesday 19th June 2018 02:49 GMT Olivier2553
Re: Because computer dates are numbers but real dates aren't
"The calendar is extinct
Not if you're dealing with historical material."
That does not make it less extinct. Like Latin is an extinct language, even if there are professors still teaching Latin.
I would also assume that historians are not much concerned about the way a computer may handle dates, it is not like your old manuscript is getting out of stock any soon.
-
-
-
Monday 18th June 2018 18:57 GMT Anonymous Coward
Re: Because computer dates are numbers but real dates aren't
> and the start of the year isn't necessarily the first of January.
Correct. For example in Catholic countries, dates between 25 December and 31 December in documents more than about 130 years old required context or expert local knowledge to disambiguate the year.
-
Tuesday 19th June 2018 01:29 GMT Diogenes
Re: Because computer dates are numbers but real dates aren't
I show this to my students when talking about times & dates. Then there are the complication of the different centuries, eg this year 2561 in Thailand , 1436 in muslim countries, and don't get me started on the 12 years of the French Revolutionary calendar
https://www.youtube.com/watch?v=-5wpm-gesOY
-
-
-
Monday 18th June 2018 17:28 GMT Anonymous Coward
Re: Because computer dates are numbers but real dates aren't
That's an "assumption" you'll find in bold type in a highlighted box in my code. I really don't "expect" anyone to be using dBase II, III or Clipper but "it's the military, stupid." God, that's going back to things I still shudder about.
-
Tuesday 19th June 2018 08:22 GMT Tweetiepooh
Re: Because computer dates are numbers but real dates aren't
xBase did store dates with 4 character year but lots of coding just used 2. This did mean that rewriting a hospital PAS from Clipper 87 to Clipper 5 didn't need huge changes to the data. And you could change the epoch such that 2 digit year could be interpreted differently depending on usage. So in 1990
DOB : 31/05/91 would store 31 May 1891
Appointment : 31/05/01 would store 31 May 1991
-
Wednesday 20th June 2018 16:55 GMT SpottyOwl
Re: Because computer dates are numbers but real dates aren't
I was involved in writing a few systems for the local NHS in the 1980s and 1990s, using Clipper. I bottled out and stored all dates as strings in the YYYYMMDD from the beginning and so had a slight overhead in some aspects of processing but indexing, grouping, etc. was easy.
I was asked to confirm in writing (and, for all I knew, sign my life and first-born away) that the system was Y2K compliant. I took the easy option, said that my software was, their hardware...maybe...other software involved...certainly not, and so I couldn't sign off.
As they say, I never worked in that town again. :-)
Ironically, through the early 2000s I got contacted by other NHS units that was using the software I'd written that I didn't know had it, and they had no problems. I must have got something right.
-
-
-
-
Tuesday 19th June 2018 11:45 GMT Anonymous Coward
Re: Because computer dates are numbers but real dates aren't
"'Not yet' which is different from 'unknown'."
We have had an issue at work (hence AC), trying to explain why putting "not provided" in a field (like serial number) isn't the same thing as "none". "None" implies the data does not exist, while "not provided" implies the person collecting the data was too lazy to record it - for a required field.
-
-
-
Monday 18th June 2018 09:04 GMT Nick Kew
why in the blue blazes would a supermarket have its own date format?
People have already pointed to the multiplicity of (non-)standards. Things were probably even more chaotic when the system was first designed. And who knows, maybe it had gone through something more esoteric, like the software I once had the misfortune to encounter where all the time&date code (among other things) were completely screwed by porting to a different-endian architecture.
But more importantly why is a format like that not documented and given to all developers?
You must be young! Corporate documentation walks faster than a ripe cheese. Pre-google, it was rare indeed to be able to lay hands on anything that wasn't too patronisingly obvious for anyone to have bothered to nick it. Even if it existed, expect it to describe something that needs you to perform - say - endianness magic (never imagined by the writer) to work.
And to be written to corporate processes. The bit you need was chopped as "too complex" by the tech writer's boss. Any surviving note is buried in a disused septic tank behind something more intimidating than a mere "beware of the leopard" sign (icon for one prospective layer of cover).
-
Monday 18th June 2018 11:51 GMT xeroks
why in the blue blazes...
why in the blue blazes would a supermarket have its own date format?
One of my first employers stored future dates and and thus encountered the millennium bug very early.
They had been aware of the problem well before that, but because storage was still expensive, they put it off for a few years. Adding a digit or 2 to all dates was a big deal, requiring the whole database to be unpacked and repacked. It would have taken more than a weekend on the hardware of the time.
They worked around it for awhile by turning the last digit of the year into an alphanumeric (yes it was COBOL) so 2000 was 9A, 2001 was 9B etc.
They had come to a longer term fix by the time I left, just before they ran out of letters.
-
-
Monday 18th June 2018 09:21 GMT Anonymous Coward
While I can't speak to supermarkets but while I wore the uniform, we had a unique format for dates on requisitions. You took the last digit of the year and tacked that in front of the day in Julian format (YDDD with DDD being count of days since first of the year.) I had all kinds of fun coding around that. Not just getting a valid date into the supply system, I also had to be able to reverse that from normal calender that we use for all other purpose. Lastly, I needed to be able to do arithmetic in this Julian. Almost forgot. All of it had to be validated (sanity-checked) as I do create contracts for everything I've ever coded and ruthlessly enforce them.
F*ck this up and it's a general courts martial that results. Good fun.
-
Monday 18th June 2018 18:36 GMT Ken Moorhouse
YDDD with DDD being count of days since first of the year
There is a variation of that spec which can be encountered in industry: DDD is the count of days since first of the year, except leap years where 29th Feb is daycode 366. All other days in a leap year have the same daycode as they would have in a non-leap year. Arguably more consistent in some perverse way, but not good if thinking of sorting by these codes to check stock rotation.
YDDD also depends on maximum life of any item to be less than ten years.
-
Monday 18th June 2018 19:22 GMT Anonymous Coward
Re: YDDD with DDD being count of days since first of the year
> YDDD also depends on maximum life of any item to be less than ten years.
Not really, just use base 64 or so and you get 64 years of 262144 days each (naturally, you will be zero-based, why waste a perfectly good number when space is at a premium?).
Still a problem? Switch to Unicode!
Still a problem? Switch to Unicode code points!
-
Monday 18th June 2018 20:19 GMT Ken Moorhouse
Re: just use base 64 or so and you get 64 years of 262144 days
The beauty of a system like YDDD is that it is easy to understand and it does the job that it is intended to do. I just happen to have a habit of documenting the snags when putting forward a point of view. For supermarkets and related industries a ten year shelf-life is unthinkable:
-
-
-
-
Monday 18th June 2018 19:51 GMT Deltics
Why not use a standard date format ? Time Machine.
You saw the part where it was mentioned that this was running in a mainframe environment ?
ISO-8601 was first published in 1988.
Chances are the data on the mainframe had been around for decades before anyone thought of the need to standardise on date formats and was governed by more practical (at the time) considerations such as the need to save space, optimise processing efficiency etc etc within the constraints of what are likely to have been some very idiosyncractic/esoteric qualities of the runtime environment.
So fine, years later these new standards come along and processing power and storage efficiency are no longer the constraints they once were, and now you're only challenge is to convince the bean counters that they really should invest their beans in refactoring ALL of the date handling code in their systems which currently isn't broken at the opportunity cost of any amount of other value-add work in those systems together with the risk of introducing defects in systems that otherwise are working perfectly.
Good luck with that.
As for the documentation part of your question: What is highly likely to have happened here is that the date conventions in use were indeed very thoroughly documented but thanks to wilful misinterpretation of the Agile Manifesto (among other things) nobody believes in documentation these days (until AFTER they have learned how important it is). The developer might even have been told he had to read that documentation. Perhaps he even had read it in order to pass a control gate, but didn't actually take it in. Or perhaps they had read it years before, hadn't had to deal with date values in data for so long that they had forgotten or simply overlooked what they knew.
Bottom line is: This sort of screw up happens. That's why we say that working software is more important than documentation, but "working" doesn't mean "compiles and runs". It does mean that, but so much more.
Which is why testing is so crucial and why you never run new code for the first time in PROD.
That's the real mind-blown aspect of this story.
-
Monday 18th June 2018 21:32 GMT Fungus Bob
"why in the blue blazes would a supermarket have its own date format?"
Can't answer that but I once worked at an electronic component distributor where the IT "guru" wrote an inventory control program in RPG II that lacked units of measure. So when you saw that you had 647 of something you had no idea if it was pieces, feet, spools, gallons, pallets or some other weird measure.
-
Tuesday 19th June 2018 14:36 GMT JulieM
Units
One of our production engineers wrote a program in Visual BASIC for MS-DOS (this was the mid or late 1990s) to extend an auto-insertion machine program for multiple PCBs on a panel. That had a choice of two measuring units: you could enter the length and width of the board in either hundreths of a millimetre or thousandths of a centimetre, and it would automagically determine which was what.
-
Tuesday 19th June 2018 15:31 GMT Anonymous Coward
"I once worked at an electronic component distributor where the IT "guru" wrote an inventory control program in RPG II that lacked units of measure. So when you saw that you had 647 of something you had no idea if it was pieces, feet, spools, gallons, pallets or some other weird measure."
We used to have similar fun ordering stationery... you would order 10 foolscap folders and would receive 10, 10 packs (of 5) or 10 boxes (of 100), depending on what happened to be in front of the person picking your order... 10 ordered, 10 picked, job done. Writing '10 boxes' on an order would not guarantee the correct amount, even where a form had a UOI (unit of issue) box
-
-
Tuesday 19th June 2018 01:01 GMT Anonymous Coward
Back during the Y2K remediation days, folks came up with a number of ways of storing 4-digit year dates (or their equivalents) in pretty much the same space that the old date format used. The folks who started this process early (maybe in the 1980s or sooner) were the most constrained here, since disk and memory were still relatively expensive back then.
BTW, back in the days when I might need to run the essentially the same SQL statement on multiple platforms (iSeries, Unix, Teradata, Windows, etc.), if there was anything that was going to give me particular grief it was probably going to be the differing date formats.
-
-
-
Monday 18th June 2018 14:45 GMT caffeine addict
They've started to censor "Head" from Lou Reed's 'Take A Walk On The Wild Side' on the radio.
Absolute Radio, by some chance?
Yeah, the line "But she never lost her head, even while giving ____" shows how stupid censoring one word is. They'd probably say "it's the meaning, not the word", but if so why have I recently heard them play the lyrics "will she go down on you in a theatre" and "she can only come when she's on top"?
Censorship is sh*t.
-
-
Monday 18th June 2018 07:33 GMT Giovani Tapini
albeit not my cockup...
transactions not being applied to accounts correctly, please help started the call.
After a great deal of digging into the system it seems that some fundamental parameters had been changed manually but nobody had restarted all the cached threads/services.
This was fairly bad as it meant that there was no easy way to identify transactions that needed to be reversed and re-applied correctly.
Spent a week or so figuring it out with the corporate involved, with quite a number of customers noticing, even though this was early in the days of internet banking.
-
-
-
This post has been deleted by its author
-
-
This post has been deleted by its author
-
-
-
-
Monday 18th June 2018 18:11 GMT Blofeld's Cat
I had a friend in the Keswick Mountain Rescue Team and they once had to assist someone who had fallen and broken their ankle on a fell adjacent to "Little Cockup" while ascending "Great Cockup".
The radio communications during the incident apparently became increasingly surreal as the journey progressed.
BTW There is another hill called just "Cockup" about 2 miles south of "Little Cockup", so that's another possible venue for our next release party ...
-
Monday 18th June 2018 07:46 GMT Mage
quietly removed from those who hadn’t.
Am I misunderstanding this? They removed points people earned?
Loyalty points on say a Tesco card are really payment for losing privacy. They are tracking what you personally bought, where and when.
XKCD Customer Rewards
-
-
Monday 18th June 2018 09:18 GMT DropBear
Re: quietly removed from those who hadn’t.
But the article seems to make it sound like the points showed up for nobody, not even once, and the customers noticed _missing_ points that couldn't possibly have been the ones supposed to be applied randomly, or maybe the confusion is even worse...
-
-
Monday 18th June 2018 07:55 GMT Anonymous Coward
Large supermarkets & banks were the first commercial organisations to embrace IT. The machines were hugely expensive and had very limited memory. The programmers were working at a very low level and concocted al sorts of schemes to reduce the amount of storage needed for both the data and the program.
Go check out "The story of Mel" for the essence of these guys.
Many years ago I worked in a bank that shall remain nameless...... their original "Internet" banking product stored transactions on the clients machine in a proprietary format.....before uploading them to the banks server over the dialup connection. Sometimes the client end would get corrupted. The solution was to get the client to backup the data onto a 3.5" floppy, send it through the post to us in the Internet banking team, we would then manually edit the disk and send it back through the post. There was no encryption....
just creative ascii. The innocence of the internet had not yet bee corrupted.
-
-
-
This post has been deleted by its author
-
-
-
Monday 18th June 2018 18:14 GMT Gene Cash
> There was no encryption.... just creative ascii. The innocence of the internet had not yet bee corrupted.
HEH. On this side of the pond, in my particular part of the US in the '80s, the power company sent an 80-column punchcard with your bill... which you returned with the bill, and they used it to process your payment.
Since my mother was a developer^W software engineer^W^W programmer, she took it to work and punched a card with a negative amount in the proper place, thus getting us credited for a nice chunk o' change.
Sigh. My mother... the hacker.
-
-
Monday 18th June 2018 08:10 GMT Anonymous Coward
In the multi-language human readable world - dates and times take many formats. I have an application that extracts the likely date content from free text postings. At the last count there were a dozen different format functions - each having to handle a number of variants within that basic format.
...and it still occasionally gets presented with new user variants that need extra coding - or a human doing the interpretation.
-
Monday 18th June 2018 13:15 GMT John Brown (no body)
"...and it still occasionally gets presented with new user variants that need extra coding - or a human doing the interpretation."
You mean like 02/03/18, 2nd March or 3rd Feb? Almost impossible to identify with certainty, even if you do know the nationality of the user. Sanity checking ism't likely to much help except in specific circumstances.
-
Monday 18th June 2018 14:19 GMT 's water music
>> "...and it still occasionally gets presented with new user variants that need extra coding - or a human doing the interpretation."
You mean like 02/03/18, 2nd March or 3rd Feb? Almost impossible to identify with certainty, even if you do know the nationality of the user. Sanity checking ism't likely to much help except in specific circumstances.
Au contraire, sanity checking reveals that any sane person would mean 18th March 2002, although they would have written it as 2002/03/18 so maybe it is still ambiguous. One from @VinceH perhaps?
-
Monday 18th June 2018 17:46 GMT Anonymous Coward
"Sanity checking ism't likely to much help except in specific circumstances."
If the day of the week is also given then any ambiguity can be reduced - although not always eliminated - by calculating the possible valid years within a tight range. That then needs to know the ways the names of days of the week might be abbreviated. In some languages they are modified (declined?) by different grammatical contexts.
Some posters use several different formats for different events on a page. If they are Europeans who are going to tour the USA then they might use the US mm/dd/yy format just for those events.
-
-
Monday 18th June 2018 08:14 GMT S4qFBxkFFg
I was doing something with java and php where I needed to apply a remove operation to all items where their "expired" date was earlier than "now". Apparently the default date/time formats in java and php were not identical - I was comparing a value in seconds with one in milliseconds, and as soon as someone used the "remove expired items" command, the database was promptly emptied of all its items.
(University group project, I wasn't popular.)
-
Monday 18th June 2018 08:59 GMT Charles King
From our Squeaky Wheel Gets the Grease Dept.
"the bonus points were honoured for those customers who spotted them and quietly removed from those who hadn’t"
Moral of the day: complain loudly every time you can, because any customer who thinks a company can be trusted to do the right thing without someone standing over them will end up sadly disappointed.
-
-
Monday 18th June 2018 10:13 GMT Hans 1
How come this is not working, must be the compiler's or interpreter's fault ...
Running anything in production without a proper testing in test environment is a big no, no, no.
Does running something again when you get something unexpected seem like a bad idea?
Or is this just me?
It is a good idea, PROVIDED:
1. You are in dev or test environment
2. You have debug statements in your code and forgot to enable them on the first run or simply want to ensure one can safely run the program multiple times. There are certainly other cases as well ...
-
Monday 18th June 2018 13:22 GMT John Brown (no body)
Re: How come this is not working, must be the compiler's or interpreter's fault ...
"It is a good idea, PROVIDED:
1. You are in dev or test environment
2. You have debug statements in your code and forgot to enable them on the first run or simply want to ensure one can safely run the program multiple times. There are certainly other cases as well ..."
Yes, I don't think a time frame was mentioned in the article. It wasn't unusual many years ago to be working on a live system because there was no test environment. Having said that, I would always run something like that which would do the "change" but not write it back, write to console or printer instead so I could eyeball what was likely to happen before committing any writes into the database.
-
-
-
Monday 18th June 2018 17:53 GMT Anonymous Coward
"There's a saying for that, along the lines of "only a fool repeats their actions expecting something different to happen"
I would agree with that - except on a number of occasions something different does happen. Perfectly deterministic - but only once you finally understand all the timing and underlying constraints.
Confirmation bias also means that people stop testing when something appears to behave as they expected the first time.
-
Monday 18th June 2018 14:18 GMT Killfalcon
(some dates fudged because I can't recall when this actually happened, but it's wasn't actually this year)
"Why do we have pension schemes for 5 year olds?"
"Oh, that's a savings product, set up in the kid's name by the parents. Government scheme, even."
"Neat, sounds like a useful product. And this minus 7 year old?"
"...I'll get back to you."
** two days, several meetings and a few minor recriminations later **
"It was Excel, and 2-digit years for data-entry work. Any 2-year date below 30 is assumed to be a future date, so a pensioner born in 1925 is coming through as born in 2025, seven years in the future, hence -7. A very annoyed senior data-entry clerk is now re-doing that batch, muttering unpleasantries about co-workers."
-
Monday 18th June 2018 16:01 GMT Anonymous Coward
Never mind the date... what about that algorithm?!?!
Lots of (justified) complaining about the date format but what about that algorithm?
“This was on an IBM mainframe and involved writing a script to extract all customers to a file, remove staff, contractors, their relatives etc, extract the random 1000 and create a database load file consisting of account ID, number of points and the date to be applied.”
Wouldn't it be rather less processing effort to pick a random account, then test for eligibility, then append to the load file if okay? [1] Stop after 1000 found.
[1] The story's modern enough to relate to loyalty points so I assume we're not still on tape storage with sequential access only.
-
Monday 18th June 2018 17:34 GMT Stoneshop
Re: Never mind the date... what about that algorithm?!?!
[1] The story's modern enough to relate to loyalty points so I assume we're not still on tape storage with sequential access only.
The story is clearly dealing with, er, legacy issues if not actually happening several decades ago, given that custom date format which is something you decide to use if you're strapped for space Maybe the environment has been upgraded and space is not the issue it was, but the date format, and probably oodles of other cruft, is still there. And the environment may well still act as if it's sequential access, like it was when the first line of code was punched.
-
-
Monday 18th June 2018 17:30 GMT Cynic_999
The Internet is international - and so are many supermarkets.
Gosh, what a lot of ethnocentric Englanders commenting today :-)
England is not the only country in the multiverse, and nor is it the only place with supermarkets and computers.
Today is 18th June 2018. In England.
In Islam it's 4 Shawwal, 1439
In Persia it's 28 Khordad 1397
In Nepal it's 4th Asadh 2075
In Ethiopia it's ሰኞ ሰኔ 11 2010
In the Chinese calendar its May 5, Wu Xu Year.
The year is 5778 in the Hebrew calendar.
Then there's the Balinese Pawukon calendar which I don't pretend to understand ...
-
Monday 18th June 2018 18:05 GMT Anonymous Coward
Re: The Internet is international - and so are many supermarkets.
IIRC there are still some organisations that use the Julian Calendar rather than the Gregorian one.
In the past when England decided it would not be dictated to by Europe - there was a significant number of days difference in dates between the two calendars. When England finally made the change by advancing the date - there was discontent if not actual rioting by some people in England who believed they had just been robbed of several days of their lives.
Now - of what does that remind me?
-
-
Monday 18th June 2018 20:12 GMT Doctor Syntax
Re: The HAVE been robbed: The Internet is international - and so are many supermarkets.
"The quarter around September 1752 ... was bad news for renters."
Thanks for that. I'd not thought about quarters. Yearly contracts were adjusted by moving the financial year end back by 11 days to April 5th.
-
-
-
-
Monday 18th June 2018 19:37 GMT TheRealRoland
Date format history - somewhere?
A couple of weeks ago I watched an ancestry-type show. Documents written in England in the 1600s apparently used the mm/dd/yyyy format back then. But now almost all European countries are using dd/mm/yyyy in their day to day communications. So I guess that's where the US format came from... And got stuck, after "the rest of the world' adopted dd/mm/yyyy as the regular date format
(sure, pedants will find exceptions, already highlighted in previous posts. But in general, i'm saying).
Interesting. Probably off topic. Still interesting.
-
Monday 18th June 2018 20:43 GMT Doctor Syntax
Re: Date format history - somewhere?
"sure, pedants will find exceptions"
I don't think I've seen one that adopted that. Things were generally spelled out, often using regnal years - in fact the realms covered by the regnal years still included France well into the C17th.
Here's a Derbyshire lease: "the twelfth day of September in the fourth year of the reign of our Sovereign Lord James ye second by the grace of God England Scotland France & Ireland King defender of the faith &c Annoq Dom one thousand six hundred eighty eight "
That one was on the cusp of replacing regnal years by AD years. A few decades later and into the C18th this is the somewhat terse date of my 6x great grandfather's Will: "the twenty first day of October Anno Dmi 1720".
By the time of my 5x great grandfather's Will this had got abit more wordy: "dated this twentythird Day of November in the Year of our Lord one Thousand seven Hundred forty and nine".
That continued into the C19th with my 3x ggfather: "the twenty seventh day of July in the year of our Lord one thousand eight hundred and fourteen".
-
Tuesday 19th June 2018 06:41 GMT onefang
Re: Date format history - somewhere?
"the twelfth day of September in the fourth year of the reign of our Sovereign Lord James ye second by the grace of God England Scotland France & Ireland King defender of the faith &c Annoq Dom one thousand six hundred eighty eight "
Obviously they didn't have space issues when trying to squeeze that onto computers.
-
-
Tuesday 19th June 2018 12:16 GMT Anonymous Coward
Re: Date format history - somewhere?
"But now almost all European countries are using dd/mm/yyyy in their day to day communications. "
Back in the 1970s I found that in Sweden they often used yyyy mm dd. Can't remember what the separators were - but I adopted that order for all my IT work with dated file names as it sorts into a sensible list.
-
-
Monday 18th June 2018 22:25 GMT Anonymous Coward
“This was on an IBM mainframe and involved writing a script to extract all customers to a file, remove staff, contractors, their relatives etc, extract the random 1000 and create a database load file consisting of account ID, number of points and the date to be applied.”
Pardon me for not being a mainframe guy (I'm a bit too young for all that), but surely that's like 1 SQL query?
-
Tuesday 19th June 2018 11:35 GMT Killfalcon
It's probably doable with one, but if you're being cautious (or have low memory limits) you'd almost certainly want to do it in steps, so you can check each step in turn did what you thought it should. I mean, say you started all that and it failed because one of the tables was too long, or you misnamed the family-of-staff field, or the contractor flag turns out to be a Y/N text field not a Boolean and one entry is "Gibraltar", or whatever, you'd at least be able to see what had worked!
Ironically, that extra complication is, IME, what leads to missing minor quirks like the date format being odd. You can get too focused on checking you're actually removed the contractors or what have you, especially if there does end up being any trouble-shooting.
-
-
Tuesday 19th June 2018 09:45 GMT Sequin
I worked on an old database system for the Home Office (UK Gov Department) that ran on an OS called BOS - It could not handle dates natively, so all date fields were actually character fields and the users had to enter date in YYYYMMDD HHMMSS format for them to work correctly in the daily reports that they had to produce for ministers. Most of the support on the system was fixing dates that had been entered incorrectly as there was no validation on input.