What about locale-sensitive output?

Question

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

• Next Friday the 13th and my own
• Day of the week of the next Feb 29th
• How much snow did you get? and my own

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.

Answer 1

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.

Answer 2

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.)

Answer 3

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.

Answer 4

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.

Answer 5

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.