Sophos Cloud Optix
British seaside resorts are famous for their piers, walkways that stretch out over the sea so that visitors can get the feeling of being “at sea” without actually boarding a boat and risking sea-sickness, and without even having to set foot on the shingles/gravel/mudflats/sand of the beach at all.
In their Victorian heyday, piers were quite the tourist attraction, featuring shops, fairground rides and even theatres suspended over the water, but the mixture of steel supports, corrosive seawater, winter storms, wooden decking and mains electricity made them prone to fires and collapse.
Nevertheless, those that survived and have been restored to their former glory have been enjoying a renaissance in popularity in recent years… at least until coronavirus lockdown.
Fortunately for the operators of the Palace Pier in Brighton, England, a relaxation in English lockdown rules from early April 2021 meant that visitors could return.
They brought their coronavirus-friendly credit cards with them to pay for admission fees, rides and – of course – the fairground staple known variously around the world as candy floss, cotton candy, ghost breath, fairy floss, Daddy’s beard and no doubt many other names that disguise the marketing-unfriendly fact that it is, in fact, 100% refined sugar.
English piers aren’t particularly cheap to visit – they do require a lot of maintenance, after all, as the numerous ruined examples around the British coast will remind you – but a trip to one, even for the whole family, certainly isn’t supposed to cost thousands of pounds.
However, as reporters from the UK’s Guardian newspaper report, a few unlucky visitors who went to the Palace Pier shortly after lockdown restrictions lifted did indeed end up getting charged that much.
Intriguingly, the people affected by this SNAFU somehow didn’t get charged for their April 2021 visit back in April 2021, as you might expect.
Apparently, their payments were only put through two months later by the processor WorldPay, at the end of June 2021.
Unfortunately, the delay also brought with it another glitch, namely that the batch of payments put through were billed using the date as the amount.
One visitor to the pier, who told the Guardian she expected to be billed about £85, ended up getting billed £2104.08 for her visit on 08 April 2021 (2021-04-08.)
In a small mercy, Worldpay seems to have gone with the rather Y2K-unfriendly date format YYMMDD rather than the more robust and reliable YYYYMMDD, or else she might have ended up paying £202,104.08.
The good news is that now the reason for the miscalculations is known, the batch of defective transactions has been identified.
As a result, anyone affected in this incident ought to receive a refund, although they may, of course, end up with their card frozen or overdrawn in the interim, which could have a knock-on effect on other payments.
What to do?
- Check those statements. As we’ve suggested before, don’t just look out for transactions that shouldn’t be there. Be wary of outgoings that you expect to see on your statement that don’t appear in a timely fashion. It’s tempting to ignore missed payments in the hope that the vendor simply neglected to charge you and therefore that you “got a freebie”, but it’s more likely that something went wrong, and you might end up getting billed later on when you don’t expect it.
- Don’t use YYMMDD when recording dates. In this case, the use of YYMMDD limited the maximum erroneous debit to under £2200, given that we’re not in AD 2022 yet (although debits of £202,100.00 and above would probably have exceeded the transaction limit and wouldn’t have gone through at all), but that’s not the point. Record dates and times unambiguously, ideally using a text-based format that cannot be misinterpreted as, or automatically converted into, a number at all. See RFC 3339 for advice.
- Use cash if you are uncertain about how your payment will be handled. Cash takes up a bit more space in your wallet than a credit card, but most local vendors we know readily accept cash even if they have signs out preferring card payments during the coronavirus pandemic. For small payments, cash is convenient enough, as well as being better for your privacy.
By they way, the Bank of England’s £50 banknote, featuring perhaps the most famous computer scientist of all time, Alan Turing, officially went into circulation this week.
So all English banknotes are now made of polymer, and can be cleaned with a sanitiser spray if you’re worried about infection.
Another tip. Most credit cards these days let you configure alerts on your card. For myself, I receive an alert via text message and e-mail whenever there is a charge over $100, so a glitch like this would have been detected within seconds of the merchant submitting the charge to the bank – giving me plenty of time to dispute the charge.
slow news day?
Not really. I am not a journalist so I can allow myself to be more interested in the lessons we can learn form stories, and more intrigued by the wacky ones, than a pure news focus would require.
Having said that, it was a *Fri*day :-)
I agree about the date format. YYYYMMDD has been the international standard since the 1990s, followed by T and any number of digits when a time is needed, e.g. YYYYMMDDTHHMMSSss to a hundredth of a second. It ensures a smooth progression over the Y2K threshold.
Even worse is the traditional format of 26/6/21 or 26/06/21 (DD/MM/YY). And the worst of all is the US 06/26/21 (MM/DD/YY). In my job as a military aviation meteorologist from 1961 to 2001, we were required to use a format such as 26 JUN 2021 to avoid confusion within NATO and ICAO.
RFC 3339 demands not merely YYYYMMDD etc., but the longer format that we use on Naked Security, like this:
YYYY-MM-DDTHH:MM:SS.sssssssssZ
where T is literally a “T” and “Z” is the time zone. You are allowed to put “+1” (e.g. BST) or “-8” (e.g. PST) and so on but *always* using a literal “Z” (for Zulu time, i.e. UTC) neatly removes any mistakes due to time zones and makes all timestamps directly comparable. Removing the time zone when you record the data means you can concentrate on getting it right exactly once instead of having to renormalise the data every time you process it.
You don’t need to put fractional seconds, but using the same number of digits every time and the standardised “Z” timezone means your timestamps sort naturally into chronological order. Allowing up to 9 fractional digits might seem bizarre (nanoseconds) but computer speeds are so fast these days that milliseconds aren’t anywhere near enough and even microseconds aren’t always quite precise enough to order two sequential events in some system logs any more.
The dashes (hyphens) and colons in the date and time add a little extra space but make each overall datum much more readable to humans as well as much easier to recognise reliably (and thus not to mistake for/convert into a single number) with software.
As for written dates in regular prose, I do much like you do: DD Monthname YYYY. I always add a leading zero to DD so that you don’t have to wonder if a digit was omitted or not needed. If I need a consistent length I take the first three letters of the month name in English.
(Weirdly, UK rail tickets use the unusual list of abbreviations JNR FBY MCH APR MAY JUN JLY AUG SEP OCT NOV DMR, presumably so that no month is just one letter away from any other in the case of Jan/Jun/Jul or Mar/May but why DMR and FBY? No one seems to know.)
Thus the forthcoming double celebrations of Canada Day and Independence Day happen on 01 July 2021 and 04 July 2021 respectively.
where you say use cash i thought the whole point whilst covid is around is to not use cash. i have spent less than £30 in about 15 months
Some small businesses simply won’t take cash, but many will accept it even if they have signs out to say they prefer cards. I just ask nicely, wear a mask, keep my distance, and make a visible point of disinfecting my hands before ordering. They don’t even need to touch the cash with their bare hands. (If I can’t pay the right amount I will just pay extra or use my card on that occasion.)
So I suspect that I am asking the baristas at my local coffee shop to accept a trivial risk when handing over two metal coins with freshly sanitised hands than the risk I experience myself from the hundreds of people every day around town who still have no idea how far 2m is after more than a year of being told to keep that far from other people.
Lots of people *can’t* get payment cards, and some prefer not to have them in order to keep their spending in check. I don’t think there is anything in the English coronavirus regulations that compels the use of cards, although there is correspondingly no obligation on the part of a shopkeeper to accept cash in the first place.
(Some sorts of cash being “legal tender” doesn’t mean that you can demand to buy an item with cash and that the shopkeeper has to accept. As far as I know, it merely means that you can’t be prosecuted for failing to pay a debt that was already agreed to if you have offered and are able to pay in “legal tender”. My understanding is that if you say that you are only able to pay in cash then it’s up to the shopkeeper to decide if they want to accept the deal on those terms. Many shops in England don’t like to take £50 notes, for instance, or will refuse banknotes from Scotland or Northern Ireland, because they just don’t feel familiar enough with them to spot a dud.)
I’m very much the opposite to you in that regard.
If a shop is cash only they don’t get my business, not out of any malice or point scoring, but simply because it’s 2021 and I don’t carry cash anymore.
Few shops are cash only. At least round where I live. Sometimes their card scanner might break and they have no choice…
…but I almost always have both card and cash. (Artisan shops actually make a bit more money when you pay cash because there is no transaction fee levied by the payment processor for your convenience. I often pay cash just for that reason. When I am buying a simple coffee, what value did the payment processor add to the farmer who grew the beans? The roastery across town that prepared them? The barista who made the drink?)
“Record dates and times unambiguously, ideally using a text-based format …”
Ideally, use a proper data type, and don’t store dates as text at all. 🙂
A text string that unambiguously represents timestamps in a well-defined and structured way *is* a proper data type. The problem with predefined “date types” in various programming environments is that they are rarely unambiguous or standardised and are almost never binary compatible.
Unix uses seconds since 1970. Windows uses 100 nanosecond intervals since 1601. Excel starts, when, is it 1901?
Is your year value stored as a short int? Long int? Singed or unsigned? Heck, could be a float for all I know.
The problem with “proper” binary data types is that they often aren’t “proper”, don’t sort lexically, can’t be losslessly converted to other “proper” formats, aren’t human readable and are useless in log files.
If you’re storing the value in a text/xml/json file, then an unambiguous string representation is your only option.
If you’re storing the value in a proper database, then almost all DBMS have at least one data type designed for storing dates and times. Using it will prevent you from storing invalid values, as well as decreasing the storage size required. The database access API will take care of converting the value to the appropriate type for the programming language you’re using, so you don’t have to worry about parsing a string or converting a platform-specific binary value to the correct date/time value.
When you’re not restricted to string values, the storage options in decreasing order of preference would be:
* A specific date/time data type.
* An unambiguous integer representation – eg: yyyyMMdd for dates, HHmm / HHmmss for times; it usually takes up more space than a specific data type, and allows invalid values, but it takes less space than a text representation.
* An ISO8601 text representation – yyyyMMddTHH:mm:ss.fffffffzzz. It takes up the most space of the available options, and allows a wider range of invalid values than an integer representation; but it is at least unambiguous, and fairly simple to parse.
RFC 3339 (my link in article) and ISO8601 cover identical ground. For me, this is the first and best choice, not the last, as you claim. Using “an integer to represent the date” is not self-documenting, is not human readable, is inconsistent (given how many different epochs there are – you can’t compare two integers from different databases because one might have started life as Unix time and the other have come from Windows).
Date-as-integer also has the potential to be misrecognised in some other calculation, as happened here. (Monetary values should ideally be bound to their currency as well, because a value without its unit is essentially valueless, but that is another issue.)
Splitting up dates and times is also best avoided so that they always stand together – vital for logging and forensics purposes.
So, I hear you but I still don’t agree with you.
“But most local vendors we know readily accept cash” ? I can’t remember the last time I needed to pay cash for something. During Covid-19 we were encouraged to use card-only, cash wasn’t even accepted by a lot of retailers.
You rarely need to pay cash. I wasn’t suggesting it was compulsory – just a small, privacy enhancing trick that you can use if you wish.
In my experience, every time I decided to pay cash, notably for small amounts like £2, I never had an objection. And all large stores in my area readily accepted cash (though I rarely used it for speed reasons) because a significant minority of people either cannot or do not wish to use a card.
The government also encouraged people to cut down on car use. As a cyclist I didn’t notice much of that – the roads where I live are roughly as choked and the supermarket car parks as full as ever.