We've been here a few times, as I recall:

All of those solutions may or may not fail, depending on the user's locale when executing them. I for one strive to solve problems that are robust under those assumptions, but is it viable to assume some common execution environment for golfing?

The problem then is that you can offload quite a bit to your locale – I'm using German with ISO-8601 date format, so I usually cannot use format strings to output fractional numbers, but I can just use the short date format {0:d} to output dates in YYYY-MM-DD which obviously is a slight advantage when that's the desired output format for a program. I suffer again with days of the week which come out as Montag instead of Monday but that's fine since I have enumeration values in English handy.

Of course, such things could be handled in the individual tasks, but maybe a general guideline would be better.

Another way to circumvent this would probably be to restrict oneself to exact string output or integral numbers (floating-point numbers may be given in a variety of formats with , as the decimal point or some languages might do scientific notation with e+25 by default, so they may require some working around in some cases). To put all date solutions on a common ground this might call for a very custom format, made-up names of the days or just the day number.

Or we could just say that all solutions are expected to be run in a en-US locale.

Am I seeing problems where none are? :-)

It's just that I find solutions that require different degrees of preconditions hard to compare with each other.

Here's an extreme proposal.

• You're allowed to submit code that works in C for free.

• Other than that, you declare your locale in your profile, don't change it too often (I'll check :p ), and are allowed submissions in that locale only.

Actually, I'm more concerned about the problems being locale-centric than the solutions.

• That sounds like a nice one. Now the question is, how do I get a "C locale" on my Windows, whatever that may mean here. You know, there are other systems out there than Unixoids :D – Joey Mar 27 '11 at 10:55
• As for the problems, I guess anything that calls for a date in a certain format or floating-point numbers in a certain format is problematic. Maybe that should be noted in the FAQ that that can lead to hard-to-judge answers. – Joey Mar 27 '11 at 10:56
• +1 for the point about problems being the problem. – Peter Taylor Mar 27 '11 at 14:17
• @Joey I don't know Windows systems well enough to think of anything there. Feel free to suggest! – J B Mar 27 '11 at 17:15
• Again, as for the problems; the single date problem I posted deliberately used only integers in output to sidestep locale issues. – Joey Mar 27 '11 at 17:34

It may help to use a common locale, but en-US is not it. (Does anyone really want to standardise on middle-endian dates? ;-)) C might be, though! :-P (For people not familiar with locales, the C locale basically provides locale-insensitive behaviour for locale-sensitive programs.)

• Of course, en-US has the worst date format ever heard of, despite ISO standardizing a sane one :-) – Joey Feb 18 '11 at 23:06

Date stuff is a mess for golfing anyway since task complexity vary depending on what your datetime library can do.

In total, all this is mostly related to the problems of golfing in different languages.

• Not only date stuff. Floating point numbers can be difficult as well since the decimal separator (and the group separator) can vary. – Joey Mar 21 '11 at 19:29
• The separator is a smaller problem, especially because most languages default to . no matter local settings, you might be the only user to whom that is a problem. If you just drop PowerShell the problem will be solved ;-) Or you could just pretend to be American and not know. – aaaaaaaaaaaa Mar 21 '11 at 19:56
• I'm not the only one with , as the decimal separator on this site. And not only PowerShell but nearly every language will respect locale settings (hopefully) if you output a floating point number as a string. IIRC even C does that (which says a lot already). – Joey Mar 21 '11 at 20:00
• C? Not with my compiler. – aaaaaaaaaaaa Mar 21 '11 at 20:31
• What lib is that? Anyway, not really relevant for golfing if you have to do the incantation to experience the problem. – aaaaaaaaaaaa Mar 21 '11 at 23:33
• @Joey, I much prefer it when I have to tell the language which locale to use and otherwise it uses sensible defaults. (NB In .Net CultureInfo.InvariantCulture isn't sensible. For some reason it uses middle-endian dates rather than ISO standard). – Peter Taylor Mar 27 '11 at 14:18

I can only support a suggestion that we default to an Culture Invariant locale for the simple reason that these are guaranteed not to change. It could become jolly difficult to test old answers if the local they depend on changes.

For .NET this would be https://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo.invariantculture%28v=vs.110%29.aspx which I presume corresponds to the "C" locale mentioned else where.

I've also seen some concerns in some languages with locale implementations on different OS', so even if they aren't changing they may be a pain to test on different systems. Hopefully everyone can make their Culture Invariant locales correct.

As stated prior, this is pretty much "en-US", so most everyone will comply without even realising.

As long as it works in some locale, and you specify the locale, it's fine. This is parallel to our rule about compiler-specific solutions.