4 ms·

I think this is because its so difficult to support all the different options, like languages and different calendars ...but you're right: getting English + Gre

I think this is because its so difficult to support all the different options, like languages and different calendars ...but you're right: getting English + Gregorian consistently right would be a start!

kuschku 10y ago
That alone is hard. I’ve got a version of Chrome here that, if you query with .value from JS the value of a datetime-local field, returns you a String in "MM/DD YYYY" format. Despite the user’s locale being de_DE. I’ve also discovered one browser only supporting ISO8601, and another only support it if one removes the time section of it. Another only if you have a time section, but remove the time zone part at the end. It’s such a horrible mess.
- jstanley 10y ago
  > Despite the user’s locale being de_DE. Surely you're not suggesting that the representation of the date that is returned by the browser should be locale-dependent? That would be a nightmare.
  - kuschku 10y ago
    Well, it’d be less of a nightmare than returning it in a random locale! At least when it’s locale-dependent I can use a look up table and parse it somehow, but getting it back in MM/DD YYYY? I’d love to just get ISO8601 ideally, btw, but who knows if that will ever happen. (Also, you should check out Microsoft Excel, its date type and CSV converter are both locale-dependent. Locale of the program opening the file, not the file itself. A file created in de_DE will be unusable in en_US)
    - rch 10y ago
      Do not look at Excel when thinking about appropriate handling of dates and times.
      - mathw 10y ago
        It makes a fantastic checklist of things you shouldn't do while handling dates though!
- TeMPOraL 10y ago
  One would think it should be simple in principle. User side: just show/accept whatever the site owner wants, or if it's too difficult, stick to ISO 8601 (it's the standard, damn it). JS side: just ISO 8601.
  - skrebbel 10y ago
    Why ISO? JavaScript has had a Date type since forever.
    - TeMPOraL 10y ago
      So Date type, then, but if we're talking input fields, they're also meant to be used with forms submitted without all that JavaScript cruft on top. So if you have to convert the date input to text for sending (or direct retrieval in code), I'd say just stick to ISO. Why? Because it's a standard.
      - skrebbel 10y ago
        Ahyes, I'm so stuck in JS-o-world that I forgot there's an actual text format called HTML. Thanks :-)
  - hibbelig 10y ago
    Why the format the site owner wants? Why not the format the user wants?
    - TeMPOraL 10y ago
      That could be a reasonable default, but you need to give the programmer control over the format, or else everyone will keep using JS-powered replacements.
- adrianratnapala 10y ago
  WPF Datagrids have a "currency" format. This defaults to dollars regardless of your locale.

kuschku 10y ago

That alone is hard. I’ve got a version of Chrome here that, if you query with .value from JS the value of a datetime-local field, returns you a String in "MM/DD YYYY" format. Despite the user’s locale being de_DE. I’ve also discovered one browser only supporting ISO8601, and another only support it if one removes the time section of it. Another only if you have a time section, but remove the time zone part at the end. It’s such a horrible mess.

jstanley 10y ago
> Despite the user’s locale being de_DE. Surely you're not suggesting that the representation of the date that is returned by the browser should be locale-dependent? That would be a nightmare.
- kuschku 10y ago
  Well, it’d be less of a nightmare than returning it in a random locale! At least when it’s locale-dependent I can use a look up table and parse it somehow, but getting it back in MM/DD YYYY? I’d love to just get ISO8601 ideally, btw, but who knows if that will ever happen. (Also, you should check out Microsoft Excel, its date type and CSV converter are both locale-dependent. Locale of the program opening the file, not the file itself. A file created in de_DE will be unusable in en_US)
  - rch 10y ago
    Do not look at Excel when thinking about appropriate handling of dates and times.
    - mathw 10y ago
      It makes a fantastic checklist of things you shouldn't do while handling dates though!
TeMPOraL 10y ago
One would think it should be simple in principle. User side: just show/accept whatever the site owner wants, or if it's too difficult, stick to ISO 8601 (it's the standard, damn it). JS side: just ISO 8601.
- skrebbel 10y ago
  Why ISO? JavaScript has had a Date type since forever.
  - TeMPOraL 10y ago
    So Date type, then, but if we're talking input fields, they're also meant to be used with forms submitted without all that JavaScript cruft on top. So if you have to convert the date input to text for sending (or direct retrieval in code), I'd say just stick to ISO. Why? Because it's a standard.
    - skrebbel 10y ago
      Ahyes, I'm so stuck in JS-o-world that I forgot there's an actual text format called HTML. Thanks :-)
- hibbelig 10y ago
  Why the format the site owner wants? Why not the format the user wants?
  - TeMPOraL 10y ago
    That could be a reasonable default, but you need to give the programmer control over the format, or else everyone will keep using JS-powered replacements.
adrianratnapala 10y ago
WPF Datagrids have a "currency" format. This defaults to dollars regardless of your locale.