[Development] QLocale - Date/Time Changes Still Required

[John Layt]

Hi,

Two essential areas need to be addressed.  While these could be left for 5.1, 
I believe it would be far messier as a result because we would have 2 
different API's that are subtly different and would lead to confusion and 
inconsistencies.

1) Change the Qt string format codes used to the CLDR/ICU standard:

   Milliseconds - Change from z to S
   Timezone - Change from t to z
   AM/PM - Remove AP, ap and A, a uses default case
   Day name - Change from ddd and dddd to EEE and EEEE
   Year - Change behaviour of yy and yyy
   Hour - Change behaviour of hh and HH

The only way to introduce this in 5.1 would be to have completely different 
names for the methods which would lead to confusion:

  QString toString(const QDate &date, const QString &formatStr) const;
  QString formatDate(const QDate &date, const QString &formatStr) const;

2) Change format/parse API to support CLDR/ICU formats.  This is primarily to 
split the FormatType enum which mistakenly merges the format and field 
lengths, and remove separate standalone name methods, so currently:

  enum FormatType { LongFormat, ShortFormat, NarrowFormat };
  QString toString(const QDate &date, FormatType format = LongFormat) const;
  QDate toDate(const QString &string, FormatType format = LongFormat) const;
  QString monthName(int month, FormatType type = LongFormat) const;
  QString standaloneMonthName(int month, FormatType type = LongFormat) const;
  QString dateFormat(FormatType format = LongFormat) const;

This would ideally be fully replaced with:

    // CLDR format length attribute for date/time/number/currency
    enum StringFormat {
        FullFormat,
        LongFormat,
        MediumFormat,
        ShortFormat
    };

    // CLDR field width attribute
    enum FieldFormat {
        LongName,      // e.g. January
        ShortName,     // e.g. Jan
        NarrowName,    // e.g. J
        LongNumber,    // e.g. 01
        ShortNumber    // e.g. 1
    };

    // CLDR context attribute
    enum FieldContext {
        FormatContext,        // Use in a format
        StandaloneContext     // Use standalone
    };

  QString toString(const QDate &date, StringFormat format = FullFormat) const;
  QDate toDate(const QString &string, StringFormat = FullFormat) const;
  QString monthName(int month,
                    FieldFormat format = LongName,
                    FieldContext context = FormatContext) const;
  QString dateFormat(StringFormat format = FullFormat) const;

In my current code, this completely replaces the old enum and methods, but if 
a compatabiltiy API is required the old enum and methods could be retained 
with the new StringFormat enum using different names like FullPattern.

Note the old FormatType::LongFormat actually maps to StringFormat::FullFormat.

Combined, there are two options:

1) Keep one consistent API, minimise source compatability break by providing 
deprecated enum methods, but force everyone to switch to new format codes.

2) Add a second API in 5.1 with different and inconsistent names like:
  formatDate()
  parseDate()
  datePattern()

Option (2) just seems messier to me and more prone to confusion, with 
inconsistent and less elegant method and enum names.  If it is only added in 
5.1 then people will start writing new clean Qt 5.0 code but still using the 
old format/parse API and then have to change in 5.1.  It may also mean we have 
to keep the original parse/format code even after switching to ICU.

Option (1) may or may not be painful depending on how common it is to use 
custom date format patterns.

Note I only show the date api above, this also applies to the time and 
datetime as well.

Cheers!

John.