Den 01-12-2015 kl. 16:02 skrev Murphy, Sean:
Den 30-11-2015 kl. 18:43 skrev Murphy, Sean:
I'm having an issue with multiple locales in my application and I'm
trying to understand what the best fix should be. Our application is
being used in two places right now: China & the US. One of the
functions of the application is to log data samples to a csv file.
Another function is to be able to load that log file back in later to
look at the data.
I fix this problem by setting the locale temporarily to a known state before
loading or saving files. This blog entry is about exactly this
problem: http://www.vikingsoft.eu/blog/?p=21
I hope this helps,
Thanks Bo! I think in my case the answer will be to modify my application to write out
the data using a standard, locale agnostic format, so I could either use the QLocale::c()
version or using Qt::ISODate or Qt::RFC2822Date. That fixes the problem going forward -
new files will have date/time information written out the same regardless of the user's
locale. Technically the way I was logging data was poorly thought out to begin with since
it in no way accounted for timezones, I was writing the date/time out in "ddd
MM/dd/yyyy HH:mm:ss.zzz" format. So sure, you'd know that this sample was recorded
on Monday, November 30, 2015 at 13:52:19.428 in someone's local time, but you would have
no idea in what time zone that was done. Using Qt::ISODate or Qt::RFC2822Date fixes that
for me.
Once I make that change, I only have to deal with existing files that were recorded under the old format where the date
portion was done as "ddd MM/dd/yyyy". For those, it's really only the "ddd" part that is locale
dependent and is screwing me up. That is redundant data anyways since I have the day, month, and year data right after
it. So the easiest fix is to read in the string, remove the first 4 characters (the "ddd " portion) and then
use QDateTime::fromString(data, "MM/dd/yyyy HH:mm:ss.zzz") to read those in.
And then you have similar problems with QString::number, QDomDocument or
any of the others that I have seen with this kind of problem.
Sure, you might test yourself all the way out of this to a working
solution. And then in three years someone else uses QDate::toString the
wrong way and you release the new version. And then you are ****ed again.
If you write something in a file that you later parse, you absolutely
must set a known locale before the writing is done. Whether this is C
(which is probably best) or US or anything else is irrelevant. As long
as you do it.
Next step I'd do is to unit test this with something like
1) Set some weird locale
2) Call the write function
3) Set another weird locale
4) Call the read function
And repeat with a bunch of locale combinations. I'd also throw in a set
of known good and bad files to test with.
With this, you will be fairly sure that your application won't ever
bitrot in this area. Without it, there's pain waiting for you.
Bo.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
