[Development] Contributing to Qt session at Qt World Summit
Hi, Yesterday morning at the Qt World Summit we had a session about contributing to Qt. I was really happy to see over 80 people joining the session at 8 am before the second day keynotes (and after a great party the previous evening). We actually run out of chairs in the room we had booked for this, so quite many had to stand. We discussed about the various ways of contributing (also other than source code), showed hands-on how a code contribution is done, and had a panel discussion about contributing to Qt. Hopefully we encouraged new contributors. Yours, Tuukka ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Porting QT to new OS
On 7/11/19 3:42 PM, Thiago Macieira wrote: On Wednesday, 6 November 2019 20:41:10 PST martin ribelotta wrote: This question is in the air time to time but the information is very disperse and not so convincent for me. Actually in my understand, Qt need: 1) POSIX compliant base (pthreads? mmap? fork?) I can disable parts individually or need some kind of #ifdef sparse by the code? I see some kind of preprocessor magic scattered in the code like this: https://github.com/qt/qtbase/blob/4b0af2cdbf61572b22ea6b8aa17fc9f52c71ac4b/ src/corelib/thread/qthread.cpp#L174 Yes, POSIX compliant base including pthreads and filesystem API. What the filesystem API accesses is irrelevant, it just has to exist. Threading support is mandatory in Qt, even though there are #ifndef QT_NO_THREAD around. Those aren't tested and aren't guaranteed to even compile. You can try that at first, but I recommend aiming for full threading. Actually, QtWebAssembly platform is a supported platform and default is nothread. :) What is not tested is nothread on a different platform like desktop. -- Lorn Potter Freelance Qt Developer. Maintainer QtSensors, Qt WebAssembly ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Porting QT to new OS
On Wednesday, 6 November 2019 20:41:10 PST martin ribelotta wrote: > This question is in the air time to time but the information is very > disperse and not so convincent for me. > > Actually in my understand, Qt need: > > 1) POSIX compliant base (pthreads? mmap? fork?) > > I can disable parts individually or need some kind of #ifdef sparse by the > code? I see some kind of preprocessor magic scattered in the code like > this: > https://github.com/qt/qtbase/blob/4b0af2cdbf61572b22ea6b8aa17fc9f52c71ac4b/ > src/corelib/thread/qthread.cpp#L174 Yes, POSIX compliant base including pthreads and filesystem API. What the filesystem API accesses is irrelevant, it just has to exist. Threading support is mandatory in Qt, even though there are #ifndef QT_NO_THREAD around. Those aren't tested and aren't guaranteed to even compile. You can try that at first, but I recommend aiming for full threading. > 2) QPA plugin > > Minimal is a good start point? I only have a framebuffer in memory > directly accessable for the CPU and vsync interrupt (with manual page > flipping) Yes, that's minimal's purpose: something to get you started. > 3) Support for atomics in target architecture? > > In my case maybe it wouldn't be a problem, the target is ARMv7 in thumb2 > mode Atomics are mandatory. ARMv7-A and R have support for them. I don't know about M and don't know about Thumb support. Lacking atomic instructions is not an excuse. Atomics can be emulated with locks. Also, since you'll be running with no MMU and single processor, maybe regular accesses are atomic enough. > 4) What about the memory footprint? A couple of megabytes. > What are the hot spots of qtcore in consumption? Impossible to say without knowing what features you left enabled. > I'm followin the Qt for MCU project with great interest but in this > moment, my clients are looking for something really minimal like > freeRTOS, and my intention is to evaluate the work for port Qt to > this. > > Intuitively, it seems that port qt to a non-posix system can be a > titanic task, but at least I want to evaluate the manpower for this. Yes, don't go there. The only non-POSIX system supported is Windows. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Porting QT to new OS
Hi guys, I'm evaluate, for a client, the cost of port Qt to a bare metal RTOS with minimal (realy minimal) requirements like freeRTOS, mbedos etc (no mmu, no mmap, no filesystem, etc) What is the minimal requirement to run Qt in a really minimal platform? (for now, qt in my words is understand as corelib, gui and widget in the minimal expression) This question is in the air time to time but the information is very disperse and not so convincent for me. Actually in my understand, Qt need: 1) POSIX compliant base (pthreads? mmap? fork?) I can disable parts individually or need some kind of #ifdef sparse by the code? I see some kind of preprocessor magic scattered in the code like this: https://github.com/qt/qtbase/blob/4b0af2cdbf61572b22ea6b8aa17fc9f52c71ac4b/src/corelib/thread/qthread.cpp#L174 2) QPA plugin Minimal is a good start point? I only have a framebuffer in memory directly accessable for the CPU and vsync interrupt (with manual page flipping) 3) Support for atomics in target architecture? In my case maybe it wouldn't be a problem, the target is ARMv7 in thumb2 mode 4) What about the memory footprint? What are the hot spots of qtcore in consumption? I'm followin the Qt for MCU project with great interest but in this moment, my clients are looking for something really minimal like freeRTOS, and my intention is to evaluate the work for port Qt to this. Intuitively, it seems that port qt to a non-posix system can be a titanic task, but at least I want to evaluate the manpower for this. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Two-digit dates: what century should we use ?
On Wed, Nov 06, 2019 at 12:38:48PM +, Edward Welbourne wrote: > want. Sample options: > * keep 1900-1999, discourage use of ShortFormat; > * rolling window based on currentDate(), as I described earlier; > * we update startYear's default with each major release of Qt. First option seems to be the one least surprising. > For the last, for example, we could make startYear=1940 in Qt6; by the > time we get to a major release in the late '20s, we'd be ready to move > that to startYear=1950. I guess we can be confident of at least one > major release per not much more than a decade, which suffices to ensure > that dates throughout the supported life-time of that release do > round-trip, while reaching well into the past. That's assuming > range=100: if we use a buffer zone, range=90 for example, we'd probably > want Qt6 using startYear=1950 already (so '40s are invalid and '30s are > the 2030s). > > Any objections to this revised plan ? > Anyone want to make the case for keeping 1900--1999 as default ? You mentioned other systems that used that approach. I would expect interacting with such systems is easiest, if the rules are the same. A shifting window would probably be unique to Qt, i.e. cause friction in all cases. > Or for my earlier dynamic floating-window proposal ? > Or any other suggestions for the default ? > If not, the update at major release - a.k.a. static floating-window - > looks the sanest to me. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Two-digit dates: what century should we use ?
Hi, On 05-11-19 14:44, Edward Welbourne wrote: Hi all, Prompted by [0], I'm looking at what century to use for years, when the text being read is expected to be in a "short format" that only includes two digits. * [0] https://bugreports.qt.io/browse/QTBUG-74323 tl;dr - how do folk feel about (in Qt 6) a century-wide window, ending a decade or three ahead of QDate::currentDate(), and placing any two-digit year in that range ? Before anyone says "Don't Do That" (or "why would anyone use two-digit years after the mess of y2k ?"), bear in mind that CLDR (the Unicode consortium's common locale data repository, on which QLocale's data is based) provides short date formats, many of which use two-digit years. We currently fail to round-trip dates via such formats because 1900 is used as default year when no year is specified and (thus) 19 is used as default century number when only the later digits are (understood to be) specified. As we get further into the twenty-hundreds (as it were), this shall grow to be an increasing jarring flaw in date format handling. I'm considering changing that: since it's a material behaviour change, it clearly needs to happen as part of Qt 6, which at least gives me a few months to discuss it and see what folk think is a better plan than what we have. It's notable that ECMAScript's Date constructor adds 1900 to any year number from 0 through 99 (even if supplied as one of a sequence of integer arguments, not a string), causing problems for the representation of dates from 1 BCE through 99 CE. (I must remember to tease my friend on the ECMA 262 committee about that - his excuse will be that it was copied from an early version of Java, I suspect - and see if he can coax them into changing it.) Likewise, C's struct tm (used by mktime and friends) has a 1900 offset on its year number: that's probably never going to change, perverse as it is and shall increasingly be. Folk still talk about "The fifties" and mean the 1950s; probably likewise the forties, thirties and even twenties. That last, at least, shall soon be something of a problem. Folk can see more of the past than of the future, so perhaps it's not much of a surprise that common nomenclature reserves short phrases for the past at the expense of the future: "The sixties" shall be in the past for a few decades yet, I think. So rather than having a default century, and maybe changing it abruptly to 20 at some point in the next fifty years, I think it would be better to have two-digit years coerced into a century-wide window about the (forever moving) present. Perhaps we should make that a narrower window and treat roughly a decade near the wrap-around as error - e.g. using 1945--2035 as our year range, with two-digit years 36 through 44 treated as undecodable. The question then arises: what year-range should we use ? Two things I'm fairly sure should be true are: * the current year (i.e. QDate::currentDate().year(), naturally) should be included in the range; * the range should be contiguous. So the interesting questions are: * how far into the past and future should the range reach ? * how wide a buffer (if any) should we leave ? If we don't have a buffer, my inclination is to put the transition date at a decade boundary, e.g. 49 -> 2049 but 50 -> 1950, as this shall feel less perverse to most folk than having a mid-decade transition such as 44 -> 2044 but 45 -> 1945. However, with a buffer, this problem goes away, as there aren't adjacent two-digit numbers that map to wildly different years; instead, the intervening numbers that aren't handled make the discontinuity seem more sensible. In principle a one year buffer would suffice, but I'm inclined to make the gap a decade long, or more, if we have one. If QDate::currentDate().year() is C and (C / 10) * 10 is D, either of these ranges strikes me as better than the 1900--1999 that we're currently using: * D -70 <= year < D+30 (all two-digit values handled) * C -65 <= year <= C +25 (othet two-digit values rejected) So, to my questions: * Does anyone want to make the case for keeping 1900--1999 as range ? * Has anyone a better suggestion for how to chose a rolling range ? * Should we have a buffer ? If so, how wide ? * How far into the past and future should the range reach ? I came to the conclusion that the sane behavior for interpreting dates depends on the semantics of what the date means. For instance, a birth date will always be a date in the past, while a date for an appointment would normally be a date in the future. That alters the interpretation of the date. May I suggest adding an enum argument to any function doing the conversion from a string to a date that allows you tell you to suggest the kind of date that is expected? I think it would come in four flavors. 1) A default `aroundCurrentDate` value or something like that that would result in using a window where the date is interpreted as being in the window of the current year -
Re: [Development] Two-digit dates: what century should we use ?
On 11/6/19 1:38 PM, Edward Welbourne wrote:
>
> Anyone want to make the case for keeping 1900--1999 as default ?
Yup, I'll bite, for the following reasons:
1) The downside of changing it is certain: breaking existing apps. In
particular, breaking the old code dealing with old data, which is the
parts nobody knows anymore or want to touch...
2) The upside is uncertain: as the discussion has shown, there are a lot
of different ways to change it; whatever we choose will only match the
expectations of a subset of users. The app developer will most likely
end up having to deal with the issue explicitly anyway.
3) It will add to the industry confusion in an already dysfunctional
field. "How will 2 digits be interpreted? Well, is the app Qt-based or
not? Is it Qt 6 or earlier?"
4) At some point in the not too distant future, some standards
organization or industry consensus may establish a "best practice" for
this issue. At that point we must add support for that - and would
rather not have to also maintain any home-invented alternative behaviour
(for backwards compatibility), adding to the chaos.
Just my 2c :)
BTW, I also had the thought that just adding a parameter of type
enum TwoDigitYearBase { EpochCentury, CurrentCentury }
to the relevant apis would solve most common cases (with the default
being EpochCentury, i.e. 1900) ?
Although the suggested (startYear, span) api is certainly also useful
for more complex usecases.
- Eirik Aa.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Two-digit dates: what century should we use ?
Eike Ziller (6 November 2019 09:45) > It sounds to me like any automatically chosen base for 2-digit years > will be wrong depending on use case. You (among several others) make a compelling case. > If you want to make it easier for people to implement their > interpretation of 2-digit years, you could add an (optional) explicit > window to the QDate::fromString API? That sounds like an excellent plan. I could even implement it in 5.15 as a new overload. Simplest would be to have two optional arguments, startYear and span; in 5.15, startYear must be supplied (to distinguish this overload from the old method) but span can be optional, defaulting to 100 (also used if span < 0 or span > 100). The old method will behave as if it were the new method with startYear = 1900, span = 100. (We could specify endYear instead of span, but its default gets trickier.) Two-digit years then get mapped to a year with startYear <= year < startYear + span. If there is no such year with the given last digits, the field is treated as unparseable. Using span=0 breaks short formats, but we can accept that as a deliberate choice some client code may make. There then remains the question of what the default should be in Qt 6 (where we'll naturally unify the overloads). If that's not 1900--1999, then we should deprecate the old method at 5.15 and encourage its callers to explicitly pass 1900 as startYear, if that's really what they want. Sample options: * keep 1900-1999, discourage use of ShortFormat; * rolling window based on currentDate(), as I described earlier; * we update startYear's default with each major release of Qt. For the last, for example, we could make startYear=1940 in Qt6; by the time we get to a major release in the late '20s, we'd be ready to move that to startYear=1950. I guess we can be confident of at least one major release per not much more than a decade, which suffices to ensure that dates throughout the supported life-time of that release do round-trip, while reaching well into the past. That's assuming range=100: if we use a buffer zone, range=90 for example, we'd probably want Qt6 using startYear=1950 already (so '40s are invalid and '30s are the 2030s). Any objections to this revised plan ? Anyone want to make the case for keeping 1900--1999 as default ? Or for my earlier dynamic floating-window proposal ? Or any other suggestions for the default ? If not, the update at major release - a.k.a. static floating-window - looks the sanest to me. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Two-digit dates: what century should we use ?
> If you want to make it easier for people to implement their interpretation of 2-digit years, you could add an (optional) explicit window to the QDate::fromString API? that would actually be very appreciated On Wed, Nov 6, 2019 at 11:46 AM Eike Ziller wrote: > It sounds to me like any automatically chosen base for 2-digit years will > be wrong depending on use case. > For some applications, only the past is relevant. > For some applications, dates N years into the future are relevant. > If we choose any N for a window, that can be wrong for some application. > Even if the format is Qt::SystemLocaleShortDate, we do not know if that > refers to the “current date”. > Even if the round trip is made correct for QDate::currentDate(), it will > be wrong for other dates. > API that behaves differently depending on current date becomes difficult > to test. > > If you want to make it easier for people to implement their interpretation > of 2-digit years, you could add an (optional) explicit window to the > QDate::fromString API? > > Br, Eike > > > On Nov 5, 2019, at 14:44, Edward Welbourne > wrote: > > > > Hi all, > > > > Prompted by [0], I'm looking at what century to use for years, when the > > text being read is expected to be in a "short format" that only includes > > two digits. > > * [0] https://bugreports.qt.io/browse/QTBUG-74323 > > > > tl;dr - how do folk feel about (in Qt 6) a century-wide window, ending a > > decade or three ahead of QDate::currentDate(), and placing any two-digit > > year in that range ? > > > > Before anyone says "Don't Do That" (or "why would anyone use two-digit > > years after the mess of y2k ?"), bear in mind that CLDR (the Unicode > > consortium's common locale data repository, on which QLocale's data is > > based) provides short date formats, many of which use two-digit years. > > > > We currently fail to round-trip dates via such formats because 1900 is > > used as default year when no year is specified and (thus) 19 is used as > > default century number when only the later digits are (understood to be) > > specified. As we get further into the twenty-hundreds (as it were), this > > shall grow to be an increasing jarring flaw in date format handling. > > > > I'm considering changing that: since it's a material behaviour change, > > it clearly needs to happen as part of Qt 6, which at least gives me a > > few months to discuss it and see what folk think is a better plan than > > what we have. > > > > It's notable that ECMAScript's Date constructor adds 1900 to any year > > number from 0 through 99 (even if supplied as one of a sequence of > > integer arguments, not a string), causing problems for the > > representation of dates from 1 BCE through 99 CE. (I must remember to > > tease my friend on the ECMA 262 committee about that - his excuse will > > be that it was copied from an early version of Java, I suspect - and see > > if he can coax them into changing it.) Likewise, C's struct tm (used by > > mktime and friends) has a 1900 offset on its year number: that's > > probably never going to change, perverse as it is and shall increasingly > > be. > > > > Folk still talk about "The fifties" and mean the 1950s; probably > > likewise the forties, thirties and even twenties. That last, at least, > > shall soon be something of a problem. Folk can see more of the past > > than of the future, so perhaps it's not much of a surprise that common > > nomenclature reserves short phrases for the past at the expense of the > > future: "The sixties" shall be in the past for a few decades yet, I > > think. So rather than having a default century, and maybe changing it > > abruptly to 20 at some point in the next fifty years, I think it would > > be better to have two-digit years coerced into a century-wide window > > about the (forever moving) present. > > > > Perhaps we should make that a narrower window and treat roughly a decade > > near the wrap-around as error - e.g. using 1945--2035 as our year range, > > with two-digit years 36 through 44 treated as undecodable. > > > > The question then arises: what year-range should we use ? > > > > Two things I'm fairly sure should be true are: > > * the current year (i.e. QDate::currentDate().year(), naturally) should > > be included in the range; > > * the range should be contiguous. > > > > So the interesting questions are: > > * how far into the past and future should the range reach ? > > * how wide a buffer (if any) should we leave ? > > > > If we don't have a buffer, my inclination is to put the transition date > > at a decade boundary, e.g. 49 -> 2049 but 50 -> 1950, as this shall feel > > less perverse to most folk than having a mid-decade transition such as > > 44 -> 2044 but 45 -> 1945. However, with a buffer, this problem goes > > away, as there aren't adjacent two-digit numbers that map to wildly > > different years; instead, the intervening numbers that aren't handled > > make the discontinuity seem more sensible. In
Re: [Development] Two-digit dates: what century should we use ?
It sounds to me like any automatically chosen base for 2-digit years will be wrong depending on use case. For some applications, only the past is relevant. For some applications, dates N years into the future are relevant. If we choose any N for a window, that can be wrong for some application. Even if the format is Qt::SystemLocaleShortDate, we do not know if that refers to the “current date”. Even if the round trip is made correct for QDate::currentDate(), it will be wrong for other dates. API that behaves differently depending on current date becomes difficult to test. If you want to make it easier for people to implement their interpretation of 2-digit years, you could add an (optional) explicit window to the QDate::fromString API? Br, Eike > On Nov 5, 2019, at 14:44, Edward Welbourne wrote: > > Hi all, > > Prompted by [0], I'm looking at what century to use for years, when the > text being read is expected to be in a "short format" that only includes > two digits. > * [0] https://bugreports.qt.io/browse/QTBUG-74323 > > tl;dr - how do folk feel about (in Qt 6) a century-wide window, ending a > decade or three ahead of QDate::currentDate(), and placing any two-digit > year in that range ? > > Before anyone says "Don't Do That" (or "why would anyone use two-digit > years after the mess of y2k ?"), bear in mind that CLDR (the Unicode > consortium's common locale data repository, on which QLocale's data is > based) provides short date formats, many of which use two-digit years. > > We currently fail to round-trip dates via such formats because 1900 is > used as default year when no year is specified and (thus) 19 is used as > default century number when only the later digits are (understood to be) > specified. As we get further into the twenty-hundreds (as it were), this > shall grow to be an increasing jarring flaw in date format handling. > > I'm considering changing that: since it's a material behaviour change, > it clearly needs to happen as part of Qt 6, which at least gives me a > few months to discuss it and see what folk think is a better plan than > what we have. > > It's notable that ECMAScript's Date constructor adds 1900 to any year > number from 0 through 99 (even if supplied as one of a sequence of > integer arguments, not a string), causing problems for the > representation of dates from 1 BCE through 99 CE. (I must remember to > tease my friend on the ECMA 262 committee about that - his excuse will > be that it was copied from an early version of Java, I suspect - and see > if he can coax them into changing it.) Likewise, C's struct tm (used by > mktime and friends) has a 1900 offset on its year number: that's > probably never going to change, perverse as it is and shall increasingly > be. > > Folk still talk about "The fifties" and mean the 1950s; probably > likewise the forties, thirties and even twenties. That last, at least, > shall soon be something of a problem. Folk can see more of the past > than of the future, so perhaps it's not much of a surprise that common > nomenclature reserves short phrases for the past at the expense of the > future: "The sixties" shall be in the past for a few decades yet, I > think. So rather than having a default century, and maybe changing it > abruptly to 20 at some point in the next fifty years, I think it would > be better to have two-digit years coerced into a century-wide window > about the (forever moving) present. > > Perhaps we should make that a narrower window and treat roughly a decade > near the wrap-around as error - e.g. using 1945--2035 as our year range, > with two-digit years 36 through 44 treated as undecodable. > > The question then arises: what year-range should we use ? > > Two things I'm fairly sure should be true are: > * the current year (i.e. QDate::currentDate().year(), naturally) should > be included in the range; > * the range should be contiguous. > > So the interesting questions are: > * how far into the past and future should the range reach ? > * how wide a buffer (if any) should we leave ? > > If we don't have a buffer, my inclination is to put the transition date > at a decade boundary, e.g. 49 -> 2049 but 50 -> 1950, as this shall feel > less perverse to most folk than having a mid-decade transition such as > 44 -> 2044 but 45 -> 1945. However, with a buffer, this problem goes > away, as there aren't adjacent two-digit numbers that map to wildly > different years; instead, the intervening numbers that aren't handled > make the discontinuity seem more sensible. In principle a one year > buffer would suffice, but I'm inclined to make the gap a decade long, or > more, if we have one. > > If QDate::currentDate().year() is C and (C / 10) * 10 is D, either of > these ranges strikes me as better than the 1900--1999 that we're > currently using: > * D -70 <= year < D+30 (all two-digit values handled) > * C -65 <= year <= C +25 (othet two-digit values rejected) > > So, to my questions: > *
Re: [Development] Two-digit dates: what century should we use ?
Den tis 5 nov. 2019 15:48Kari Oikarinen skrev: > > > On 5.11.2019 15.44, Edward Welbourne wrote:> Hi all, > > > > Prompted by [0], I'm looking at what century to use for years, when the > > text being read is expected to be in a "short format" that only includes > > two digits. > > * [0] https://bugreports.qt.io/browse/QTBUG-74323 > > > > tl;dr - how do folk feel about (in Qt 6) a century-wide window, ending a > > decade or three ahead of QDate::currentDate(), and placing any two-digit > > year in that range ? > > > > Before anyone says "Don't Do That" (or "why would anyone use two-digit > > years after the mess of y2k ?"), bear in mind that CLDR (the Unicode > > consortium's common locale data repository, on which QLocale's data is > > based) provides short date formats, many of which use two-digit years. > > > > We currently fail to round-trip dates via such formats because 1900 is > > used as default year when no year is specified and (thus) 19 is used as > > default century number when only the later digits are (understood to be) > > specified. As we get further into the twenty-hundreds (as it were), > this > > shall grow to be an increasing jarring flaw in date format handling. > > I think even in the future many two-digit year formatted dates will > refer to 19xx (either because they are old or because that's the > assumption widely). So correct handling of those formats will be > impossible anyway. They don't contain enough information. But it's of > course unfortunate if the dates you stored yourself can't be read back > correctly. > > > I'm considering changing that: since it's a material behaviour change, > > it clearly needs to happen as part of Qt 6, which at least gives me a > > few months to discuss it and see what folk think is a better plan than > > what we have. > > > > It's notable that ECMAScript's Date constructor adds 1900 to any year > > number from 0 through 99 (even if supplied as one of a sequence of > > integer arguments, not a string), causing problems for the > > representation of dates from 1 BCE through 99 CE. (I must remember to > > tease my friend on the ECMA 262 committee about that - his excuse will > > be that it was copied from an early version of Java, I suspect - and see > > if he can coax them into changing it.) Likewise, C's struct tm (used by > > mktime and friends) has a 1900 offset on its year number: that's > > probably never going to change, perverse as it is and shall increasingly > > be. > > Surely that's not a comprehensive list. I don't expect either of these > to change and staying in line with other software can avoid surprises. > > I thought almost everyone would assume 1900-1999 as the range. > Apparently that's not true though. Python uses the range 1969-2068 and > C# depends on locale but appears to at least sometimes be 1930-2029. > Using two-digit years is a much worse idea than I thought since there > doesn't seem to be consensus. > > > Folk still talk about "The fifties" and mean the 1950s; probably > > likewise the forties, thirties and even twenties. That last, at least, > > shall soon be something of a problem. Folk can see more of the past > > than of the future, so perhaps it's not much of a surprise that common > > nomenclature reserves short phrases for the past at the expense of the > > future: "The sixties" shall be in the past for a few decades yet, I > > think. So rather than having a default century, and maybe changing it > > abruptly to 20 at some point in the next fifty years, I think it would > > be better to have two-digit years coerced into a century-wide window > > about the (forever moving) present. > > > > Perhaps we should make that a narrower window and treat roughly a decade > > near the wrap-around as error - e.g. using 1945--2035 as our year range, > > with two-digit years 36 through 44 treated as undecodable. > > > > The question then arises: what year-range should we use ? > > > > Two things I'm fairly sure should be true are: > > * the current year (i.e. QDate::currentDate().year(), naturally) should > >be included in the range; > > I don't think it's that obvious. Many systems start at the UNIX epoch > and then may get the current time from network later. That might > result in the year-range changing during application lifetime, which > sounds horrible. You wouldn't know what certain input results into > when reasoning statically. > Agree with this 100%. I think changing the behavior depending on what date it is is a bad idea and would risk leaving software that works one day but breaks the next. I think it's better to leave people dealing with two digit dates in the awkward spot they already are, rather trying to guess what they want by using a moving window. I think it's better Qt have one fixed behavior compiled in, even if it means at some points in the future we'll have breaking behavior changes in the library, probably in major releases, as Qt
