10 ms·
Does Your Code Pass the Turkey Test? (2008)
- SideburnsOfDoom 2y agoAs for dates and times interchange, use ISO 8601 (largest to smallest order). The EU and many other countries ordering of day, month, year (smallest to largest order) also makes sense, but is sadly ambiguous due to The US format of month, day, year (middle-endian order) https://9gag.com/gag/a2KEqOe https://9gag.com/gag/a2KEqOe US not TUrkey is the outlier
- nayuki 2y agoDMY dates don't make sense. The units are from smallest to largest, but the string within each unit is still written from biggest to largest. Furthermore, if DMY makes sense, then you could argue that SS:MM:HH or MM:HH has a valid use case. (It does not.) Hence, ISO 8601 is the one true date format, assuming you still believe in writing numbers in big endian. If you want, you can argue for numbers being written in little endian. For example, the year "two thousand twenty-four" could be written as 4202, and maybe pronounced as four twenty thousand-two. In that case, go ahead and write dates as SS:MM:HH DD/MM/YYYY; it is UTC 61:45:12 60/21/4202.
- elpocko 2y agoThat's crazy. What's next, abbreviating "Coordinated Universal Time" as UTC instead of CUT?
- SideburnsOfDoom 2y ago> then you could argue that MM:HH has a valid use case. (It does not.) "twenty past ten" (It does.)
- Dylan16807 2y ago"twenty till ten" is just as valid, so I don't see either of those as a true example of MM:HH.
- mrweasel 2y ago> DMY dates don't make sense. This is a language issue. DMY makes perfect sense in languages where you'd normally say the date in that sequence. The "problem" is that English doesn't do that. The natural flow in English is MDY, e.g. July 4th, 2024. That not how Germanic language (at least those I know) works. In Danish or German you'd say "4th July, 2024", that's just how those languages work. I do agree that for computing ISO 8601 is the way to go as it sorts correctly.
- SideburnsOfDoom 2y ago> The natural flow in English is MDY, e.g. July 4th, 2024. I'm sure that's true. This seems more like US custom than the whole English language. "July 4th" sound a bit forced and not natural to me, and I am a native English speaker. Not US English though.
- SideburnsOfDoom 2y ago> I'm sure that's true. I accidentally an important word there. It should be "I'm not sure that's true." It's an English expression that's a bit understated: it means "I'm confident that this is wrong". You can't always argue from "what feels natural" - that's prone to mere familiarity (1), and someone else who is more used to the other way will have the opposite "feel". It's subjective, and not universal. 1) https://en.wikipedia.org/wiki/Mere-exposure_effect https://en.wikipedia.org/wiki/Mere-exposure_effect
- mphalan 2y agoIn England (and Ireland). One tends to say “The 4th of July”. “July 4th” is an Americanism.
- HideousKojima 2y agoBoth "the 4th of July" and "July 4th" are common in American English
- SideburnsOfDoom 2y ago
- okanat 2y agoBoth DMY and HMS are sensical notations of time. For most people the day is the most important part of the cycle in a year. We measure most of our actions and chores in days then months then years. In a meeting, in official letters, taxes etc. everything is specified in days. Similarly hour is the most common division of a day. Generally humans have an internal tendency to measure things in half of an hour interval and hour is the closest one. One usually rents a parking slot for integer multiples of an hour. The travel distances are specified in hours or fractions of it Putting the most important measure at first just makes sense.
- frizlab 2y agoMost of these problems have incorrect solution. For instance, the actual solution to parsing portrait or landscape is to not use a string for this. It should never have been a string! Other better solutions apply for the rest too.
- 9rx 2y agoThe command line is defined by strings. It had to be a string to stay within end-user requirements. You may be able to make a good case that the string input is best represented as something parseable by an existing argument parser library, but even then you are dependent on that library handling the strings correctly. Which, at best, pushes the problem onto someone else. Someone else who still has to be aware of input possibilities.
- frizlab 2y agoOh missed the context, my bad. That being said, in that case, I’m definitely not convinced by the need for toLower (:
- do_not_redeem 2y agoWhy would you accept ArBiTrArY-cased command-line arguments in the first place? I don't think I've ever seen a cli utility that accepts the wrong case. Just compare the raw bytes. `ls --ALL` doesn't work, and neither should `my_app --PORTRAIT` (no matter which "I" you type).
- kobalsky 2y agoThis is from 2008
- saaaaaam 2y agoOf course, the Turkey test itself now fails the Turkey test as Turkey has been updated to Türkiye.
- nayuki 2y agoThat was a very heavy-handed move that overrides traditions in many languages
- labster 2y agoI can’t imagine getting upset if someone wants to call my country États-Unis or 米国. Only Turks want to tell me how to speak my own language.
- FredPret 2y agoAnd Burmese / Myanmarians. Names are always bestowed, never picked.
- jltsiren 2y agoGeorgians don't seem to like either if you call their country Gruzia. And Greeks didn't like it when their neighbors wanted to be Macedonians. Names often have historical baggage, and using them may send a different message than what you intended.
- FredPret 2y agoAn interesting one is Germany. Different people call them Allemagne, Tyksland, Saksamaa, Německo, Germany, and many more; of course none of these people ever went to Germany and asked them nicely what they'd like to be called.
- guenthert 2y agoI think Tyskland is pretty close, particularly given how neighboring folks actually speak there. Allemange has reasons in history as does Germany. I suppose the others can easily explained likewise. Really, it could be much worse.
- QuercusMax 2y agoThere's one more test: the Thailand test. I've been bitten by issues in Java where Calendar.getInstance() will return a Thai Buddhist calendar, which is exactly the same as the Gregorian calendar except 543 years in the future.
- brudgers 2y agoWouldn’t issues in Java be failing “The Indonesian Test?”
- cirrus3 2y agoWhy are you using the Calendar API in Java? It is full of issues like this.
- tisdadd 2y agoI never really understood why not simply use milliseconds since the epoch and keep track of a time zone separately if needed... This allows fairly easy conversion to most native systems i have worked with, easy sorting and diff operations as well as final display control. Also don't have a need to be thinking about daylight savings then, or do other conversions for say timesheets.
- patrickthebold 2y agoIt depends on what you need to do. If you just need to say when something happened (e.g. some log event) then milliseconds since the epoch is fine. If want a user to schedule a reoccurring meeting at 8am on the first Thursday of every month, you can also keep a set of timestamps as milliseconds since the epoch, but you are going to need to do some work to figure out the right numbers correctly.
- XCabbage 2y ago> If want a user to schedule a reoccurring meeting at 8am on the first Thursday of every month, you can also keep a set of timestamps as milliseconds since the epoch No, you can't really, especially if the recurring meetings go on more than a few years into the future. If the time zone rules themselves change (e.g. if the user's country abolishes or introduces DST), then the timestamps you stored will become wrong in light of the change.
- shreddit 2y agoAh yes, ye old m/d/y - d/m/y debate. One is clearly wrong but the Americans won’t listen…
- Arch-TK 2y agoBoth are wrong, one is wrong-er. y-m-d h:m:s all the way.
- dowager_dan99 2y agopreach!
- SoftTalker 2y agoOracle's 'DD-MON-YYYY' (e.g. 06-DEC-2024) default date format always annoyed me but I have to admit it's unambiguous.
- ikekkdcjkfke 2y ago1733443200 is even more unambigous. Or is it? The date format measures how many sun-ups so it is more accurate even if time-dilation. So date format is actually just a sun position measure? Maybe we could just have a sun-ups since 1970 ticker. Edit: and i guess why have leap seconds and stuff is because we are rrying to combine both sun position and elapsed seconds idk
- 05 2y agoAttoseconds since the Big Bang is the only datetime system worth a damn.
- lucb1e 2y agoThat number could be anything, such as a user ID. Even among timestamp libraries that work with January 1st 1970 UTC as the zero point, they might parse it as January 21st 1970 if they were expecting milliseconds rather than seconds. It doesn't get much more ambiguous than a plain number!
- deleted 2y ago[deleted]
- dowager_dan99 2y agoA lot of these seem to be the "not America" test.
- jiggawatts 2y agoSomething that drives me crazy about the big public clouds is that everything is US regional defaults with - if you’re lucky - UTC as the time zone. We’ve spent easily several months of engineering time “fixing” apps that kept picking up these defaults directly or indirectly. E.g.: What regional options does Azure Data Factory use for parsing CSV by default for batch jobs if you deploy an instance in Australia East? Your guess is as good as mine! It’s especially hilarious considering that all three major operating systems ask these questions up front, just as they as for a password instead of providing a result. Vendors have had to learn the hard way that defaults for some settings are nonsense for 96% of the planet, and now the same companies have forgotten this lesson and will have to learn it all over again.
- lxgr 2y agoUTC timestamps, but displayed on a 12-hour clock, are among the most cursed things I have to work with every day. Always trips me up, and much more so than "fully US" conventions (i.e. local time and MM/DD/YYYY and am/pm timestamps). Sometimes (but not always), it helps to change the locale to en_UK. But then spellcheck becomes confusing...
- lxgr 2y agoSure, but there are degrees of "not-America-ness", and not all of the examples listed in TFA occur in all other regions. UK? So far so good: Maybe those time parsing routines will need some brushing up for the 24 hour based clock, and day and month are swapped, but at least the decimal separator is the same. And it's almost the same language, and definitely the same alphabet. France? Now you're adding accents to the mix, although in a pinch you can just drop them. (Not that it's a good idea, but there's no better solution.) But watch out: Different decimal separator! Germany? Better rethink that "just drop the accents" solution; it changes the meaning of words, sometimes drastically/embarrassingly so. However, there is a canonical way of transliterating äöü! Chinese: Obviously, abandon all hopes of using Latin-1. But at least you can use the US decimal separator again :)
- ern 2y agoOT: I like how he refers to a Hanselman post about great interview questions, and how around 40% of the questions in that post are obsolete. It shows how quickly our field evolves, for better or worse.
- fsckboy 2y agoTurkiye would like people to call it Turkiye. even Old New York was once New Amsterdam. Why? Maybe people just liked it better that way, and that's nobody's business but the Turks. https://www.youtube.com/watch?v=Uqnb_nU7RBE https://www.youtube.com/watch?v=Uqnb_nU7RBE (Istanbul is the traditional Turkic name for the city, basically a borrowed/altered pronunciation of Constantinople)
- lacoolj 2y agoI love this song but there's a house version that takes it to another level Japan = Nihon Germany = Deutschland Mexico = Meh-hee-koh Let's keep adding to the list see how many we get
- lxgr 2y ago"Türkiye", not "Turkiye". I suppose there really is something to the Turkey Test! That said, I don't know how bad ü -> u is in Turkish. At least in German, doing so often changes the meaning, and äöü have to be transliterated as ae, oe, ue instead. (Obviously a ton of software does something bad like "decompose Unicode characters and filter out non-ASCII letters" and gets it wrong, also hilariously failing the test.) And in general, sure, every country should get to decide how it wants to be referred to (although I suppose that can raise complicated questions as to who gets to decide that too), but in any case asking a blog from 2008 to retroactively adopt that decision is asking for a bit much, I'd say.
- notpushkin 2y agoNo idea about ü → u, but dotless to dotted i can be lethal: https://languagelog.ldc.upenn.edu/nll/?p=73 https://languagelog.ldc.upenn.edu/nll/?p=73
- lxgr 2y agoOh, German definitely has those too :)
- anticensor 2y agotuerkiye
- lxgr 2y ago> Or use the RegexOptions.ECMAScript option. In JavaECMAScript, “\d” means [0-9] which gives us: [...] Wow, the default in the Windows API does not do that? I would have 100% bitten by that at some point doing any development there, coming from a Unix background where I believe the "ECMAScript" behavior is pretty commonplace (and in fact it seems to be a subset of PCREs).
- wodenokoto 2y agoOn my phone so can’t double check, but as far as I remember neither Grep nor sed supports \d in their regex implementation.
- lxgr 2y agoAt least GNU grep supports `-P`, which makes it use PCREs (which do support \d).
- soygem 2y agoThe normal units test
- xigoi 2y agoI think the main problem here is that the behavior of the programming language is locale-sensitive by default. What languages other than C# behave like this?
- moffkalast 2y agoMost languages, I remember having rendering issues in javafx back in the day with commas and dots randomly switching in numbers depending on locale. Then again C# is a Java ripoff so maybe it's because of that, but I've seen cpp Qt apps also behave this way.
- deleted 2y ago[deleted]
- 9dev 2y agoAm I missing something? The realisation comes down to „yes, there are regional differences in formatting“, and doesn’t strike me as a particularly profound insight.
- okanat 2y agoWhen I was learning programming in 2008 as a student and was still using my computer in Turkish, the number of Java and PHP programs that did not specify a proper locale was outrageously large. For whatever messed up reasons they had lowercase / uppercase conversions for importing modules, opening files. Glibc library in Linux systems is also designed by shortsighted people so libc functions like tolower() made conversions in the local locale. The end result was phpMyAdmin usually failed with "include not found" because its developers did this: include(tolower(MODULE NAME)) and BLABLAINTERFACE was converted into blablaınterface (there is no dot on top of i there look closely). Or Eclipse failed in similar ways since it was searching plugins using locale-dependent functions.
- rideontime 2y agoMaybe this was less widely known back in 2008 when it was published? Still doesn't explain why it's getting attention now.
- kolme 2y agoNo, you're not missing anything. Anyone programming outside of the USA is well aware of localisation and how to use it.
- lucb1e 2y agoI wouldn't say that last bit though. So much code fails outside of the origin country, also from e.g. Dutch coders even though we're well aware how small our country is and how much we rely on trade and collaboration. People across the EU come into the country so you'd need to support other languages, payment methods, currencies, special characters in names, date notations, address formatting, timezones, phone numbers, etc. Part of Belgium even speaks the same language so the barrier really small, or even across the atlantic ocean where there are more people "in" The Netherlands except nobody ever realizes that a part of the country uses the US Dollar as its currency and is in a very different timezone. Now living in Germany, they even translate timezone names. Not only do you have to look in a timezone database to figure out what a MESZ is, when the timezone database says "there is no such timezone" you have to realize you need to look in a German translation of it. Very approachable for the international people that need to know which timezone that German picked for the meeting invite Which is all to say: sure, people know other countries exist and are more likely to need to learn to use localization, but by default it's not like everyone knows how to do that
- inglor_cz 2y agoSome extra tests... Central Europe has a lot of accentuated Latin characters. ěščřžýáíéů etc. Cyrillic letters are also worth trying, especially if you are trying to set up an international e-shop and need to print out labels with addresses. Spanish-speaking people tend to have very long full names, in case that a complete name is needed. Picasso was, in fact, Pablo Diego José Francisco de Paula Juan Nepomuceno María de los Remedios Cipriano de la Santísima Trinidad Ruiz y Picasso. Hungarians write surnames first, e.g. Orbán Viktor. Doing it otherwise looks unprofessional and may lead to confusion, because some first names can also be surnames. Most of Europe writes streetname first and house number second, e.g. Friedrichstrasse 52, so the other way round than Americans and Brits are used to.
- poincaredisk 2y ago>Hungarians write surnames first, e.g. Orbán Viktor. It's not only Hungary - I usually write my surname first in professional context (but both versions are OK, in general).
- eckesicle 2y agoThere’s another fun thing we can call the Britain test. The short form for September is Sept in en-GB, the only month abbreviated with four letters. It’s Sep in en-US and other en- locales. All other parsing is identical. For example, if you’re parsing abbreviated date formats on AWS, this parsing fails only on eu-west-1 and -2 servers, and only in September.
- klysm 2y agoWow that is painful. I think locales are generally net negative in such use cases
- anticensor 2y agoExample ticket: https://github.com/ROCm/ROCm/issues/2888 https://github.com/ROCm/ROCm/issues/2888
- legobmw99 2y agoOne of my first ever public projects actually had a bug report that ended up being the Turkish i problem. Didn’t know there were more!
- baxuz 2y agoIt's infuriating that most calculator apps, including the quick ones in spotlight, force me to use a comma instead of a period for a decimal delimiter.