QMacTimeZonePrivate::abbreviation() uses GMT+offset as short-form for (at least) CET

QMacTimeZonePrivate::abbreviation() delegates to the native Darwin NSTimeZone API's method [0]. Unfortunately ([1], [2]), it seems the implementation is selective about which zones to correctly handle this for; it gets PST right, but fails for CET, using GMT+01:00 instead of the proper abbreviation.

• [0] https://developer.apple.com/reference/foundation/nstimezone/1387237-abbreviation
• [1] review: https://codereview.qt-project.org#/c/177370/
• [2] log: http://testresults.qt.io/logs/qt/qtbase/f4dbd374884eb7b02019ba51dea13b949c9621b2/OSXOSX_10_08x86_64OSXOSX_10_08x86_64Clangqtci-osx-10.8-x86_64Release_NoFramework/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/testrun_1479986807/testlog.txt.gz

The relevant part of the log is:

 FAIL!  : tst_QDateTime::toString_textDate_extra() Compared values are not the same
    Actual   (dt.toString())                               : "Thu Jan 1 01:00:00 1970 GMT+01:00"
    Expected (QLatin1String("Thu Jan 1 01:00:00 1970 CET")): "Thu Jan 1 01:00:00 1970 CET"
    Loc: [tst_qdatetime.cpp(891)]

Note that the earlier PST test (for America/Vancouver) passes, correctly using PST as abbreviation; apparently a business based in that time-zone cares enough to get that one right but not enough to correctly handle CET.

This is probably beyond our power to fix, short of using a different back-end on Mac in place of the native one.