I had fun in the vmware-broadcom transition because the broadcom portal doesn't allow that, but the vmware portal did. Not even in my username, just in the surname field. The new portal ate it on that so hard, I wasn't even allowed to create a ticket to do anything about it.

Not as bad as when I was once issued a first.o'last@corp email address though ..

>Not as bad as when I was once issued a first.o'last@corp email address though

Oh, man, that happened to me too, way back in the late 90s. I had forgotten about that.

It broke things all over the place. Even now you run into the occasional validator that is convinced that the plus sign is not valid in email addresses.

> Even now you run into the occasional validator that is convinced that the plus sign is not valid in email addresses.

These are intentional IMHO - force people to use their actual email address so a potential breach can't be tied back to the service. That's the only reason why someone would use a + in the first place.

Some validators are silly regular expressions that someone wrote in a minute without thinking about it ("Mastering Regular Expressions" has a regex associated with it for better matching an address; that regex is quite the sight to behold). And disallowing + is a crummy solution to whatever "force people to use their actual email address" means given that someone with full control of a domain can invent the alias whatevertheywant@example.org instead of using something with a + in it, or they can spin up an alternate address on some alternate provider, etc.

Other reasons folks use + in their email is to do mail routing (except where crappy web services disallow the + because they relied on a crappy regex) but then again I have no idea what "potential breach can't be tied back to the service" is meant to mean.

> but then again I have no idea what "potential breach can't be tied back to the service" is meant to mean.

Easy. Say I subscribe as "username+servicename@gmail.com" everywhere, when I get spam at that email address that service must have been either breached or sold off my data.

More likely just a default.

I built the authentication system on our website and as a regular user of Gmail + aliasing I was very surprised when my brother pointed out our website didn’t allow them.

Turns out the default for Microsoft’s ASP.NET Identity Framework is to disallow special characters, but simply setting a flag in its configuration rectified this.

There may be a Unicode character that looks like apostrophe but has no quoting semantics. I use an arrow instead of greater-than symbol in my prompt for the same reason. To avoid copy/paste issues.

Non-ASCII characters in email addresses have even worse compatibility issues than punctuation characters. Punctuation fails because people don't know the standard. Non-ASCII fails because people don't know the latest standard.

> One time, one system accepted it, but another system that accessed the same data didn't allow apostrophes so the person using the second system couldn't access the record, and it took 2 phone calls and 3 people to come up with a workaround.

There's still a lot of organisations that somewhere in their e-mail processing chain cannnot deal with 4-letter TLD e-mail addresses*. Even worse is that the front-end is often a relatively new framework and will happily accept your e-mail, only to then have it silently fail forever. Mercifully a lot of those organisations have their customer service authorized to change your e-mail address manually, but if they don't.. good luck.

> And yet whenever I deal with a computer system I don't put the apostrophe in because even in 2024

In usernames or in name fields for text generally?

I assume things like bank systems can deal with it because they should match things like IDs?

Name fields in general.

But sometimes I don't have control, e.g. another person is inputting the data and dutifully duplicates my name. That's how I ended up with the 2 phone calls/3 person situation, which happened about a month ago.

Hell, my driver's license is missing the apostrophe because the system doesn't accept it.

When somebody is trying to find me in a computer there's a whole litany of things they have to try, including assuming "First O'Lastame" got bashed into "First O. Lastname".

I think about this every time I read an article extolling the wonders of technology.

Generally, countries' systems only handle characters in names that are common in that country. Virtually no banking or ID system in Europe or the USA will handle Chinese names, for example. Even if they did at the technical level, it wouldn't actually help at a holistic level, because people who interact with these systems (bank tellers, policemen, etc) can't be expected to recognize any writing system in the world.

So, the reality is that you have to adapt to the country you're trying to live or do business in and the name systems that they can actually use. This can even mean you have to adopt a name that people can actually pronounce, as many Chinese people do when interacting with people outside East Asia

For example, Chinese is particularly sensitive to tone accent, which extremely few people outside that area can even distinguish, leading to hopeless mispronunciation. Consider that Ma2 and Ma4 are completely different words for a Chinese speaker, while a French speaker who hasn't studied this wouldn't even be able to tell that you are intentionally pronouncing things differently and not just your intonation.

And for a reverse example, if you want to move or do business in Japan, you should adopt a well-known Japanese pronunciation of your name, as otherwise Japanese speakers, who have an extremely limited syllable inventory compared to most other languages in the world, will just not be able to follow your name.

That is true, but I think this example shows systems being too restrictive. If people can read Latin letters the system should accept apostrophes.