en-US and 12h time representations about d3-time-format

[mbostock]

Okay, I thought about it more, and I’ll bump this repo to 2.0. Thanks for the suggestion.

[mbostock]

Sounds like a bug in the port from 3.x?

[mbostock]

Not a bug, strictly speaking. These defaults actually come from the behavior of the date command on OS X by default:

$ date +%c
Wed Jun 22 15:33:14 2016
$ date +%x
06/22/2016
$ date +%X
15:33:19

But, I’m not sure it has to be that way. It would probably make more sense to mimic date.toLocaleString, date.toLocaleDateString and date.toLocaleTimeString. These vary a bit across browsers, but in Chrome:

(new Date).toLocaleString(); // "6/22/2016, 3:34:57 PM"
(new Date).toLocaleDateString(); // "6/22/2016"
(new Date).toLocaleTimeString(); // "3:34:57 PM"

[mbostock]

Given that I’ve already pushed a 1.0 release of this module and the behavior is consistent with D3 3.x (and date), I’m not going to change this now—it should probably be considered a non-backwards-compatible change. If you want a 12-hour time representation, then I recommend using %I:%M:%S %p explicitly and not relying on the en-US locale.

[rahulpowar]

Interestingly enough if you change your region on OS-X via Settings -> Language & Region it defaults to 12h for the US which align with Windows (as per http://travel.stackexchange.com/questions/34950/which-large-countries-use-12-hour-time-format-am-pm) and at least Chrome as you noted.

Understood r.e. the major version though given that D3v4 as a whole is still Alpha worth considering further?

Unfortunately I can't fix the format to the string as I am working on a layer that defaults to the user's culture to format dates/numbers automatically. I expect I would fork this and align them to Chrome so that the output plays nicely with the native localisation. Would you be open to breaking out the JSON configuration files into a another d3 module for d3-format and d3-time-format? It would make maintaining a parallel fork a lot tidier for me and any one else who has specific requirements. They also seem currently optional to these modules so maybe it makes sense in general?

[mbostock]

You don’t need to fork this repository simply to change the default locale or to load different locales.

Use d3.formatDefaultLocale and d3.timeFormatDefaultLocale to redefine the default locale.

For the non-default locales, simply load your own locale definitions rather than the ones in this repository. The non-default locales aren’t included in the code, so it’s not necessary to fork the code to change their definition. The locales are published to npm, but you can load them from anywhere.

Changing my region had no effect on the date command, but I do see that the OS X (er, macOS) defaults do seem more reasonable than date.

I could make this change to D3 4.0 since it is not yet released, but it would require bumping this repository to 2.0. I’m still thinking about it.