[0] https://kilianvalkhof.com/2022/css-html/are-you-sure-thats-a...
Good rule of thumb: if a reasonable person calls it a number, but your application is never going to perform arithmetic on it[0], it should probably just be a string.
[0]: Yes, a credit card number can be checksummed, but that's more in the sense of a CC# being a sequence of numbers rather than one int.
Sometimes you can get into secret menus if you play the tones for them...
I'm def. gonna try this out. I usually pres & and # a couple of times, because it often skips the useless menus and takes me to a person
Yes. Depending on your OS, it might even have the sound files:
https://pbxbook.com/other/dtmftone.html does. I'll try a company I know takes at least 40 minutes usually :
Also, something that annoys me about VOIP is that they don't take into account the different tones in different regions. Here in the Netherlands we use 425Hz fo dial tone etc. It always feels very emulated because it's a different tone.
It was mainly for doctor appointment reminders, though, so hopefully those called still had their appointments written down somewhere (or also signed up for email reminders).
The client really didn't want people sent to live agents if at all possible, as they only had a certain low number of agents and wanted to keep it that way, so we had extra prompts that tried to convince the user to give the app a try first before we did a transfer to an agent, but it was something that could start the process off.
And this was an IVR app for a Fortune 500 corporation, not a small company.
It surprised me coming from Apple Business Manager. It was unprofessional. Don’t skip the docs, guys!
Result: As expected, my problem wasn’t solved by following their 18-step DUNS/Apple process during the last 8 month. (My problem: My company changed both address and name, they still have both addresses with the old one as primary).
A faculty that was, of course, lacking at this particular organization
There's almost always a regular language more constrained and useful than .* that contains the entire set of acceptable terms (although sometimes it'll be a strict superset, in which case DFA acceptance cannot constitute complete validation).
A really small example of this is postal codes in Canada. For a long time the norm was to put a hyphen between the two clusters: A1B-2C3 but then at some point a lot of websites decided that's bad and they started rejecting it, often with really obtuse messages. This is just annoying and no one is really well served by it. Canada post doesn't care.
And that's not even getting into 0 vs O and the fact that yelling at the user for entering the wrong one is rarely helpful.
I think most of the time the better thing to do is attempt to normalize and ask the user if the normalization is correct. For a numeric thing like a phone number this is probably stripping out non-numbers (other than + at the start) and putting hyphens back in and validating the number of digits you get back, and presenting it to the user if it differs. More work but feels way less hostile to the user.
I really can't think of any case where changing a "0" to an "O" is a good idea (or vice versa), except like base 58 whre you're explicitly avoiding both.
Either way if you're going to normalize you need a regular language, so I think you're kinda missing the point here on what regular languages mean in this context?
The real point is that you want to have one regular form for the input in your database, but imposing that one that you prefer on your users creates friction when their experience of the world differs.
As for 0 vs. O, in a Canadian postal code it doesn't matter, because there is indeed a very regular language to them: letters alternated with numbers. A round circly thing in a numeric position is a 0 and a round circly thing in a letter position is an O. No matter what. The only time this actually indicates a problem is if the pattern ceases to hold after the round circly thing, in which case it may or may not be the 0/O confusion that's the problem but it was wrong anyways.
I'm not saying you should store it wrong, but if a user enters "HOH-OH0" and you ask "did you mean 'H0H 0H0'?"[1] and they say yes then you've given the user a much better and helpful flow than "Invalid Postal Code, please fill out the form again."
[1] This is a 'real' postal code btw and it goes to a weird santa-letter black hole even though it doesn't indicate a geographical location that corresponds to the north (an H prefix is for Montreal).
This is an odd case, in that the house number is a "number": in the US it generally indicates distance from some fixed line, and the parity can indicate which side of the street it falls on. But then people will write them with As, Bs, Es, etc. attached.
That sounds like it would be a better job for a linter than for a compiler.
lambda calculus tells us, stick with strings even when you're doing math
This is fairly commonly used for multi-unit dwellings, especially when someone turns a "normal" house (with a purely numeric street address) into multiple units, including renting out their basement.
In subdivisions the houses are often consecutive numbers (with odd/even numbers on opposite sides of the road), and it's not like the city is going to re-number every other house on the street.
And that's why I have a home address that doubles as an input fuzzer.
I'm not sure how mail carrier software works, but in general there's a lot of variations of the same address that still lead to mail getting delivered correctly (and some addresses where the mail can't be delivered at all)
For U.S. apartments, usually any of these work "123A Some St" "123 Some St #A" "123 Some St Apt A" "123 Some St Unit A"
USPS has a canonical list of all valid addresses. In most cases of hand written letters, it comes down to a human’s judgement call.
I live in an apartment, let's say unit 555 at 123 Main St, and my canonical address has the form 555-123 Main St. This is not unusual in any way.
It is vanishingly rare to find a business, software, or customer service agent that is willing to enter this address correctly, even when dealing with my provincial government or my federal government. They always want to put "Apartment" or "Unit", or move the apartment number after the street, or some other transformation.
And my favourite case of interesting address numbers in the US, menomonee falls, which includes addresses such as "W162N7420 Tamarack Trail" [1]
0: https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...
I run into this sort of thing somewhat frequently. A multinational food delivery company here had a period for a couple years where it'd parse "1st whateverstreet 123" as an address on whateverstreer with the number "1st", dropping the 123 entirely. This may seem a bit silly but keep in mind that over here "123 Annex B" is a valid house number for instance, which might be a different building from "123B".
I will never sum up a list of phone numbers, nor will I ever divide my CC number by two.
They’re strings that just happen to be made up of numbers.
Credit card numbers are used with numerical operations
GP is right. You never do math with two credit card numbers as inputs. You can’t negate a credit card number, or find its absolute value, or square, etc.
It’s just a string of digits.
If the number already contains the check digit, drop that digit to form the "payload." The check digit is most often the last digit.
With the payload, start from the rightmost digit. Moving left, double the value of every second digit (including the rightmost digit).
Sum the digits of the resulting value in each position (using the original value where a digit did not get doubled in the previous step).
The check digit is calculated by 10 − ( s mod 10 ) {\displaystyle 10-(s\operatorname {mod} 10)} {\displaystyle 10-(s\operatorname {mod} 10)}.The issue is that many beginner (and some experienced) programmers treat what should be opaque strings as numbers and throw them into a 32/64-bit integer, or worse, a double precision float (in JavaScript). This can result in data corruption if not done carefully. Then, when something comes in to challenge the programmer's expectations, the program breaks. For example, ZIP/postal codes are 5 numeric digits in the US, but in CA, they're of the form "A1A 1A1" (notice the space and letters). JavaScript's `parseInt` will return NaN on a Canadian postal code. Another one is house numbers; They look numeric, but can have letters or even fractions(!) in them.
Does the number 21 "contain" the number 2? Not in a meaningful sense.
However, the string "21" definitely contains the substring "2".
The digits in a credit card number are meaningless. They have no relation to each other. If you choose two digits next to each other one doesn’t represent groups of 10x as much as the other digit. Or any other quantity.
The digits are effectively just symbols, not quantities like in a mathematical representation.
inputmode=numeric
Further, for credit cards, you can add `autocomplete="cc-number"` to the input and it will provide platform-specific UI for pre-filling the credit card number.
https://css-tricks.com/finger-friendly-numerical-inputs-with...
"one hundred seventeen" vs "one hundred and seventeen" are different, 117 vs 100.17
"twenty three eights" vs "twenty and three eighths" are 23/8 vs 20 3/8.
I don't know why this idea is upsetting to people.
https://www.grammar-monster.com/lessons/numbers_how_to_write...
I think people are forgetting, before the days of numeric calculation by machines, there were rooms full of people tasked with keeping track of these things.
back when we wrote checks, you didn't write the word "and" till you got to the cents (US) on a line that was preprinted "dollars": one hundred fifty three cents dollars" vs "one hundred fifty and three cents dollars".
It's history, it's interesting, it's not meant to throw you into a panic or fits of anger. And I very much doubt that you speak for all of English speaking countries, and through history as well, but must admit you might and I'm lucky to encounter an historian of numerical orthography.
(Update: unless the units were expressed after the following number, like 5 dollars and 13 cents, which still wouldn’t express a decimal point.)
it doesn't express a decimal point if you think of cents as a completely different unit of currency from dollars, but if you think of cents as 1/100ths it actually does indicate the decimal point. "5 dollars and 13 100ths" which is what cents means, and which is sometimes used when not referring to money, for example items that are measured in centiles such as interest rates. I think our forebears were more likely to throw words like centile around, and thats how they came up with the word cents.
My cousin is Italian and he always says "for cent" to me and I scratched my head till I realized, per is translated to for from Italian, and they say "25 per cento" so he's just translating it to English as it makes sense to him, not realizing we also have the word per.
and fwiw, I don't think it's a regional difference, I think it's a difference between certain traditions within the banking and accountancy areas, vs outside.
For more interesting currency matters, go back to https://en.wikipedia.org/wiki/£sd#Writing_conventions_and_pr..., where you had three items, and “£2/4/6” would typically be pronounced “two pound, four and six” (or sometimes “two pounds, four shillings and sixpence”). This shows more clearly that what it’s a perfectly normal “and” like any other in English. (Also that conventions can certainly allow elision in understood contexts. I’ve never heard of “one dollars and twenty-three” for “$1.23”, but it would be consistent with the sorts of shortenings that sometimes happen.)
I even found this article about how "and" doesn't actually mean decimal point: https://www.grammarphobia.com/blog/2012/02/decimal-point.htm...
I think it dates from the time when the only decimals the average person would use were in currency.
Your link is the only one I could find on the first page of google that states "and" means decimal point. Every other source I could find says "100.17" is either "one hundred point one seven" or "one hundred point seventeen".
Yes, there are ways to trick Excel into interpreting the value as a string. None of them are foolproof.
It is a terrible advice, you shouldn’t use <table> for styling, but if you are representing a tabular data, by all means use <table>. I’ve heard some developers (mostly back end devs that dabble in front end) say you’re not supposed to use tables, and I’ve seen div soups where there definitely should be tables. And I blame overuse of the rhetoric “don’t use <table>”.
By all means, if your taking in a numeric value, use <input type=number>. You get frontend validation, localization, context aware soft-keyboard, accessibility etc. all for free. Use it.
If however, you don’t have a numeric value (e.g. a value that is simply represented with digits) use something else. In general, if ordering values makes sense, then most likely <input type=number> is your best choice.
In the real world, however, the browsers apparently a) don't prevent users from entering incorrect values b) don't allow the developer to do anything about it programmatically, by preventing access to these incorrect values (always returning empty).
The author brings attention to this problem.
Now it's up to you as a developer to decide whether the benefits of using <input type=number> outweigh the costs, but the costs are real and you need to be aware of them.
If you want to deal with inconsistent (and possible eccentric) user input: Use input.valueAsNumber
If you want to distinguish between empty and invalid inputs: Use input.validity.valid or input.validity.badInput
If you want to programmatically deal with incorrect entries: Again use the constraint validation API.
the developers obviously did not realize that social security numbers may start with a leading zero. (so can postal codes!)
The approach just seems to be asking for identity theft/fraud...
On the one hand a ssn number(or any identifying number) should not need to be any more secret than the name it is replacing, your ssn should be able to be publicly available.
However, this is the real world and many people and institutions use the ssn as the sole source of identity, which means it needs to be kept secret.
The SSN does not have the attributes of a good permanent identifier of a unique person. If you get an SSN with three consecutive 6's in it, you can get it changed to another one not containing that string. Worse yet, the Social Security Administration has reserved the right to reuse the SSN's of persons deceased (IDK if they can or might do that without giving further notice). Furthermore, the US government talks as if there are two completely different kinds of numbers that each use 9 digits, and that they might overlap, ie use the same numbers for different entities; one being SSN's and ITINS, and the other EINS. However, the practice of the IRS and SSA has been to do their best to make sure that they do not overlap, at which the results have been as good as can be expected, but not perfect.
As many games have been lost by one card too many as by one card too few.