Closed Nadahar closed 5 years ago
Do you think a call to TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
is needed to avoid the SO issue?
Do you think a call to
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
is needed to avoid the SO issue?
No, on the contrary, I believe that a library has no business setting any global defaults, including the default timezone.
To me the SO issue seems to be a simple misunderstanding of how things work. There's a difference between a Date
instance and the "string representation" of a Date
instance that is produced by toString()
. When calling toString()
on a Date
, it will be converted to a string using the default timezone and locale. This conversion only affects the string representation, not the Date
instance itself. All Metadata-extractor should be concerned with is that the actual value of the Date
instance is correct - the rest is mere presentation and should be left to the application using Metadata-extractor.
I believe that a library has no business setting any global defaults
Agreed. Setting the default time zone will result in a lot of traffic on our issue tracker 😄
@drewnoakes I've updated the PR. Did you mean something like this? Feel free to suggest corrections to names, descriptions, location etc.
LGTM
Thanks everyone!
Thanks Drew!
This isn't a fully tested PR, think of it as a suggested fix. My very simple testing indicated that this fixes #408, but proper review/testing should be done.