51–60 of 144 posts
Curious to wonder how many academic papers/other kinds of analysis have perhaps come to incorrect conclusions because of these date inconsistencies!
Related story from a few years ago: https://www.theverge.com/2020/8/6/21355674/human-genes-renam...
Earlier quoted context omitted.
That because Excel defaults to treating numeric data as a number and leading zeros are extraneous and it will strip them off before storing the value (and it will right justify the display). The root issue is that zipcodes though numeric in content (at least in the US) should not be treated as number (data type) but instead as a text (string) value To tell Excel to treat this numeric data as a string you to either *…
Leading zeros are not extraneous and should not be removed though
Joel Spolsky mentions a more charitable take on this from Ed Fries:
> Lotus had to fit in 640K. That’s not a lot of memory. If you ignore 1900, you can figure out if a given year is a leap year just by looking to see if the rightmost two bits are zero. That’s really fast and easy. The Lotus guys probably figured it didn’t matter to be wrong for those two months way in the past.
https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
I would be careful on dates not just before 1582 but before 1753. Great Britain and its colonies (which included USA) did not change to Gregorian until 1752 and also to confuse more changed the date on when the year changed from March to 1st January. If you are in Greece or Russia be even more aware as that will be around 1920 when they changed.
The correct date for Easter was a huge deal in the early Church. The Pope brought Easter back into conformity with Nicaea by reforming the calendar -- astronomical knowledge had improved a lot over the centuries.
Earlier quoted context omitted.
That because Excel defaults to treating numeric data as a number and leading zeros are extraneous and it will strip them off before storing the value (and it will right justify the display). The root issue is that zipcodes though numeric in content (at least in the US) should not be treated as number (data type) but instead as a text (string) value To tell Excel to treat this numeric data as a string you to either *…
Leading zeros are not extraneous and should not be removed though
The one that always bites me is Excel truncating the leading zero in US zip codes (they start with 0 in the Northeast US). I’m wondering if that would have happened if Microsoft was located in Boston instead of Seattle.
Earlier quoted context omitted.
in my country you read and speak numbers 97 like 'seven and ninety'. this is normal.. :p aslong as we dont base our endianess on how french pronounce or read nrs i think we can work with it. that being said, i am for ISO notation if you want to order something in a list. year, month, day seems logical in this case as it will easily sort chronologically. i dont see another real reason why one would be better than anot…
> aslong as we dont base our endianess on how french pronounce or read If you're annoyed by French numbers (which come from Gauls counting in 20s) try numbers in Danish.
Consider "halvtreds," the Danish word for 50. A reasonable person might expect it to mean "half-three" based on pattern recognition and the fact that tre is three. But no! It's actually a compressed version of "halvtredsindstyve," meaning "half-third-times-twenty" or (2.5 × 20).
This continues with "tres" (60), "halvfjerds" (70), and "firs" (80)—all using a vigesimal system that, if you studied French, seems reasonable.
Except, well, the Danes don't properly sanitize their inputs. "femoghalvfjerds" (75) translates to "five-and-half-fourth-times-twenty," combining decimal and vigesimal systems with zero regard for foreigners...
The one that always bites me is Excel truncating the leading zero in US zip codes (they start with 0 in the Northeast US). I’m wondering if that would have happened if Microsoft was located in Boston instead of Seattle.
You don't want to know how many phone numbers in various databases show up in exponential notation. Not gonna talk about it.
Earlier quoted context omitted.
(For good reason) Language is a picky thing in Canada, it's very important (when selling to the federal government or Québec) that both English and French localizations have equal footing. To open a en-US XLSX file in a fr-CA copy of Excel, you will need the en-US language pack. If you make this a requirement for a Québec government entity... you will not get that contract.
> To open a en-US XLSX file in a fr-CA copy of Excel, you will need the en-US language pack Are you sure? That sounds insane. Maybe if you're exporting a CSV where you insert the formulas as text, and expect the Excel to do some magic conversion.. I'm pretty sure that XLSX file is "universally" openable, and the user using the fr-CA copy of Excel will see =SOMME( ... ), doesn't matter what locale the source Excel is.…
Earlier quoted context omitted.
(For good reason) Language is a picky thing in Canada, it's very important (when selling to the federal government or Québec) that both English and French localizations have equal footing. To open a en-US XLSX file in a fr-CA copy of Excel, you will need the en-US language pack. If you make this a requirement for a Québec government entity... you will not get that contract.
> To open a en-US XLSX file in a fr-CA copy of Excel, you will need the en-US language pack Are you sure? That sounds insane. Maybe if you're exporting a CSV where you insert the formulas as text, and expect the Excel to do some magic conversion.. I'm pretty sure that XLSX file is "universally" openable, and the user using the fr-CA copy of Excel will see =SOMME( ... ), doesn't matter what locale the source Excel is.…
I also won't assume that we were making "good" excel documents. It's possible we were shipping badly made exports haha