On Tuesday 23 Aug 2011 13:41:47 Thiago Macieira wrote: > On Tuesday, 23 de August de 2011 14:00:02 [email protected] wrote:
> Uh... not exactly. Egyptian hyeroglyphs are part of Unicode and you might > run into them on webpages, so they should be properly laid out :-) > > Not that most people could tell the difference between properly laid out > and poorly done... I did learn some basic hieroglyphs at university many years ago and I doubt I can remeber the correct layout let alone the symbols, I think there was some flexibility to it :-) > > Should the default constructor go to gregorian or should it go to the one > > the user selected as his primary calendaring system? > > Trade-off. I think it depends greatly on what Gregorian methods we keep in > QDate for convenience. If there's enough of them to get by on trivial > operations, then QCalendar should default to the locale. Otherwise, to > Gregorian. > > I'm thinking that QDate should have the getters and setters for the year, > month and day, plus the ISO week and other ISO things, properly marked as > such. Those functions should operate on the proleptic Gregorian calendar > even. But the manipulation functions like addYear, addMonth, addDay, etc. > should not be there (QT4_COMPAT only). > > I'd like John's opinion here. For the new class we should default to the System calendar and empahsise this in the docs. We want devs to learn to do things the right way with the new class, if we default to Gregorian it will not be seen as any different to QDate. For QDate itself, I'm still uncertain on what should stay and what should be QT4_COMPAT, I need to think on that more as some methods are dependent on others, but I guess the minimum required for convenient Gregorian/ISO support and no more. If all the QT4_COMPAT methods need to be inline, that will also be a factor. > > >> Let's please not go into using platform dependent code (or integrating > > >> with it) for the moment. Using CLDR makes all of the code 100% cross > > >> platform and thus a lot easier to test. > > > > > >I agree. I'm just trying to find the implications. John says Windows has > > >hundreds of tiny deviations and corrections -- why are they there and > > >should > > >we have them? > > > > Yes, sounds weird. One would think that calendars are well defined and > > have a one to one mapping to a day that actually happened (ie. A number > > in julian). Unfortuately not. The individual calendars are mostly well defined in terms of ymd rules, but the jd conversion formulas are not. There's quite a few to choose from for Gregorian, mathematicians enjoy coming up with new ones. The Indian National jd conversions are well defined by an Indian law, but no others I know of are, the lawyers just don't think of it. There are no standards defined anywhere, CLDR only defines the names not the formulas. ICU implements them but I'm not convinced they're 100% accurate. In fact, I gave a talk at the Desktop Summit about starting a project to define the standards. > So, without knowing more information, I guess that Windows has those > regional differences due to political pressure of some regions to have > their calendar exactly as they want. The Windows quirks are some local variations not supported by CLDR, others are just bad coding. Need I remind of the Excel leap year bug that they later tried to fix in Excel on Mac and got it wrong a second time? Well they have bugs like that in their other calendars as well which they won't fix due to their backwards compatible policy. But we can leave that problem for later, they all fit into the standard template. John. _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
