Regression tests should not use machine's locale

[drewnoakes]

Developers currently cannot run the regression tests in locales that format things differently to en-GB (and some other English-language locales). This was identified by @Nadahar in drewnoakes/metadata-extractor#233.

The regression test program must call global setLocale(Locale.ROOT) before producing output.

Locale.ROOT is a neutral, portable locale across JVMs.

This should be compared with the equivalent issue in the .NET project.

[rdvdijk]

Another approach could be to make the Locale configurable, has that ever been considered? Instead of depending on a globally set locale, all number formatting and date formatting would use an explicitly configured one.

I do understand that this would mean that the API of ImageMetadataReader (and related JpegMetadataReader and JpegReader, and many, many other classes) would need to change to propagate such configuration to the right places.

[drewnoakes]

That would be preferable, for sure.

This issue is mostly tracking the fact that the regression tests data set breaks if you run it in a different locale to me (i.e. not en-GB).

Do you have a use case for configuring the locale?

[rdvdijk]

We use metadata-extractor in a distributed environment, setting the Locale globally has undesired side-effects. One of our clients apparently configured a different global Locale, which resulted in unexpected behavior (in this particular case: longitude/latitude formatting resulted in 'unparsable' values downstream).

We see two solutions: Tell our client to use the en-GB or en-US locale, or somehow pass a fixed Locale to metadata-extractor. The latter is the reason why I'm here 😉

[drewnoakes]

Specifying a locale across the library will be a big task and is unlikely to happen soon, though I agree it's the right thing to do.

For your specific scenario, we could override some methods for the specific tag you're looking at. Alternatively you can format the strings yourself directly from the underlying data. Lat/lng is stored as numbers internally, so you could add your own locale aware formatting without needing library changes.

Are you using the Java or .NET version? I know .NET lets you set the locale on a given thread, which would also address your issue.

[rdvdijk]

We're using the Java version. Thanks for the tip, we'll look into accessing the underlying data.

I'll also to explore this idea of passing the locale across the library. If I think it would be a feasible approach I'll send a pull request to discuss the details.