Culture-Dependent parsing of feet/inches

[pgrawehr]

(Creating an issue on this, as the task is now spread over several PRs)

Problem
As already described in PRs #794 #799 and #803, parsing Feet/inches combinations (ie. "7'23") fails for some cultures. This is because the apostrophe may be part of a number (typically as thousands separator) which makes this string ambigous.

To Reproduce
Steps to reproduce the behavior (just an example):
Run the unit tests on a computer that has the locale set to "de-Ch" (sometimes, error depends on the actual char set as number separator)

How should we proceed on this? #799 and #803 are closed, because they produce other side-effects that are equaly undesirable.

cc: @angularsen , @tmilnthorp

[angularsen]

Thanks for creating a mother of issues.

There are two issues I can think of:

1. Length.ParseFeetInches() does not support number grouping separators, effectively failing ToString/Parse round-trip for any number larger than 1000 (Fix feet inches #803 (comment))
2. Length.ParseFeetInches("1' 2\"", myCulture) fails if the culture uses apostrophe ' as the number grouping separator (reportedly with de-CH culture on @pgrawehr's PC, but a different symbol ’ is used on some other PCs) (Fix TryParseFeetInches when current locale uses ' as number separator #794)

As a start, maybe we can list the special strings we expect to be able to parse?

• Number grouping: Length.ParseFeetInches("1,500 ft 1 in", enUsCulture)
• Number grouping separator same as unit abbreviation: Length.ParseFeetInches(1'1", cultureWithApostropheNumberGroupingSeparator)
• Scientific notation: 1.2345e-3 ft (debatable, not emitted by ToString())
• Fractions: 1/2 ft or 3 ½ ft (debatable, not emitted by ToString(), double.Parse() does not support parsing these)

Implementation proposal

Example problem: Length.ParseFeetInches(1'000'000'2", cultureWithApostrophe) should return 1 million feet and 2 inches.

Algorithm:

• Split on feet abbreviations ["'", "ft"] etc to parts ["1", "000", "000", "2\""]
• double.TryParse() on consecutive parts until it fails, 1 ✔, 1'000 ✔, 1'000'000 ✔, 1'000'000'2 ❌
• Repeat similar for inches on remaining substring, splitting on ["\"", "in"] etc to get the remaining parts [2]
• Return the sum of parsed feet + inches (or just one of them, does not require both)
• Fail if not all parts are parsed.

This should work for everything that double.TryParse can eat, like scientific notation, but fractions would need extra work.

Note that we previously supported a similar summing method, but we had to tighten it so we did not allow invalid ordering like 1 in 2 ft or 1" 2' or repeating the same abbreviation 1" 2".

[pgrawehr]

Two points:

First, IIRC default ToString() does not emit number separators, so probably the default Length.ToString() shouldn't, either. That would solve the basic round-trip problem. Round-tripping is only a problem if using the "N" format specifier (or "C", but that is pointless for our case).

Second: 1'000'000'2 will not fail to parse, 1'000'000'2" will (probably a simple typo in your comment above). The parser doesn't care where number separators are (there are also cultures where grouping is not with 3 digits, but with 2).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.