I am having an issue in converting my date/time values (which are stored as Long UTC values — in milliseconds) to string represetation. After a bunch of Debugging, through the JVM source, I have determined that you guys are resetting the default TimeZone to UTC during the initialization of your BaseReader in the Flexmonster Compressor. I don’t know why you need this set the timezone to UTC, but by doing so, you have messed up all future date/time formatting in our application code, since the correct timezone is never reset (I actually need to do formatting during the processing of the compression).
I believe I can workaround this by getting the current default timezone before instantiating your CSVReader class and restoring it right after your class is created, but I don’t know what affect if any this will have on the compression functionality (i.e. not having the timezone set to UTC). Making changes of this sort without restoring the original settings is very dangerous and can lead to all kinds of subtle bugs in user applications.
Thank you for reporting.
It makes sense, we confirm that changing global application settings is a bad approach.
The fix for the compressor will be available in the next minor release (ETA Oct 23).
Does it work?
I have not noticed any incorrect behavior with my workaround, so I guess it works. Why do you need to reset the timezone in the first place??
For the most cases, your workaround will work. But in general, it can be a problem when servers are located in different time zones. As a result, same data can be parsed and shown differently.
Returning to Compressor, Flexmonster Pivot expects to receive all date data as UNIX timestamp from Compressor. So, I think, setting default time zone to UTC was used for converting purposes. But, as I already wrote, we need to find a better solution to avoid affecting user applications.
Please let me know if you have futher questions.
We are glad to inform you that the minor release 2.406 is available for download now. The issue with changing the default
TimeZone for Java Compressor was fixed. You are welcome to update the component.
I am using felxmonster v2.5 still i am facing same time zone issue.
Could you please look into this ASAP?
Please note that we have answered your question here: https://www.flexmonster.com/question/compressor-is-changing-the-time-zone-internally/.