On Monday 22 Aug 2011 09:13:21 Thiago Macieira wrote: > On Monday, 22 de August de 2011 00:13:42 John Layt wrote:
> > Ah, but in the real world, try using the current QDate formulas for any > > year before 4800 BC or after about 1.4 million AD, the formulas break > > down and give nonsense results. Many formulas have not been written to > > cope with negative years, or large values, or are simplified for speed > > in the most commonly used date range. Now, I do have better formulas > > than QDate currently has, but for some other calendar systems it is a > > limitation. > > Still, they are highly inaccurate compared to what? > > Remember we defined that there are 365*400 + 1*97 = 146197 days every 400 > years. When do they break down to that definition? OK, let me explain the main problem a little more. There's 2 key formulas, ymd -> jd and jd -> ymd. The first one is usually fairly straight-forward to define, however converting back from jd is a lot harder. Both these formulas need to match on a round-trip for them to be reliably used. For the current implementations this doesn't happen for years < 4800BC and > 1.4 million AD. If you convert 1 Jan 10,000 BC to jd and then back again you get something like 0 Jan 10,000 BC. This means you can't rely on getting back what you stored. Another example is the Persian/Jalali calendar which is really an astronomical calendar, but there's a faster maths formula that gives the correct answer for +/- 200 years that some people use. While it always cleanly round-trips it gives the wrong ymd answer outside its valid range and can't be used for interchange down the wire. > > Sorry, don't quite understand that one? Do you mean I have to define the > > QT4_COMPAT myself as an inline? Or the toString() methods have to be > > inline? > > The methods have to be inline. We can't repeat the mistake of having non- > inline Qt3Support methods. OK. The current QDate implementation is a couple hundred lines, so I guess I'll need a short conversion routine to map it to call the new QLocale api instead. > > I haven't listed the name/format/parse methods as those will be in > > QLocale, they all use the same parser/formatter code excpet the Hebrew > > language which has a few special paths. > > Will that also be true with CLDR? Hebrew language date formatting is unique. Most of the time in modern Hebrew they use normal decimal digits (123...) for numbers, including for Gregorian dates, but for Hebrew calendar dates in Hebrew language they use traditional Hebrew letters instead of digits in a non-positional system with a degree of ambiguity due to there being no letter for 0. There is some special parsing/formatting code in KDE to convert numbers to/from Hebrew letters which I assume CLDR/ICU implementations also do. See http://www.i18nguy.com/unicode/hebrew-numbers.html for more details. > > Note also that almost everything is hard-coded and accessed via methods > > not variables, the only variables are for eras which would move to > > QLocale, so there's nothing to copy. > > Sorry, I didn't understand. How would the era move to QLocale? Well, the list of Era's for any particular calendar is actually defined in the locale, i.e. the names and the absolute years they apply to. For example for the Gregorian calendar en_GB will define BC/AD but fr_FR may have a different translation of the names. For the Japanese calendar en_GB might define 2011 as Heisei 23, but in jp_JP it will be 平成 23. The locale will then also define the date format to either use the absoute year or era year and name. So the era api for Japanese calendar in 2011 / Heisei 23 gives you: year() returns 2011 eraYear() returns 23 eraName() returns "Heisei" toString() may return "1 Jan 2011" or "1 Jan Heisei 23" > > One thing I know I do not want is toHebrewDate() and fromIslamicDate() > > and chineseDay() all over the place, it's ugly and doesn't scale, either > > use derived classes or a common method name with a > > QLocale::CalendarSystem enum as an argument. > > What scaling is required? We've defined that we're going to support only > CLDR calendars. > > But I get the point of code duplication. Well, yeah, duplication is a better word. CLDR defines 13 calendars, Windows supports a different 13, a total of 18 different calendars would make for a lot of confusing methods, hence a common class with an enum being better. John. _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
