Results 1 to 9 of 9

Thread: Extending QDate, QTime and QDateTime

  1. #1
    Join Date
    Jan 2006
    Location
    11 N 78 E
    Posts
    110
    Thanks
    10
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    Unix/X11

    Default Extending QDate, QTime and QDateTime

    Dear all,

    I have been trying to modify the qdatetime* files to the following ends:

    1. Push the earliest date back to -4000 Jan 01 from a meaningless 1752 date
    2. Allow the client programmer to read the internal representation in milliseconds of QTime
    3. Rename QTime::mds and ds() to something more sensible.
    4. Add a function to return a QTime value as a fraction of a day.
    5. Add a function to return an astronomically valid Julian Day Number from a QDateTime value.


    But somehow I am not able to get the stuff to compile correctly. There are too many errors to fit on screen. I have based my modifications on the Qt 4.11 qdatetime* code. Please help me with accomplishing my target successfully.

    P.S: Another important matter -- when I modify a GPLed program, the resultant program is copyright me or the original author?
    Attached Files Attached Files
    Penguin #395953 using Qt for open-source development on X11 using C++ and
    Python via PyQt

  2. #2
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    5,372
    Thanks
    28
    Thanked 976 Times in 912 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

    Default Re: Extending QDate, QTime and QDateTime

    Quote Originally Posted by jamadagni
    Push the earliest date back to -4000 Jan 01 from a meaningless 1752 date
    And why "-4000" isn't meaningless? Year 1752 is very important for gregorian calendar.
    when I modify a GPLed program, the resultant program is copyright me or the original author?
    Both. By removing the Trolltech copyright you have violated GPL licence.

  3. #3
    Join Date
    Jan 2006
    Location
    11 N 78 E
    Posts
    110
    Thanks
    10
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    Unix/X11

    Default Re: Extending QDate, QTime and QDateTime

    Quote Originally Posted by jacek
    And why "-4000" isn't meaningless? Year 1752 is very important for gregorian calendar.
    1582 was the original year of promulgation. See the Wikipedia article. There is no reason why the year of adoption of the calendar in *England* should be used. Why not in another country.

    Anyway, -4000 has as much meaning as 8000 has. 8000 is 6000 years ahead of the current important reference point which is year 2000. See:

    #define QDATE_INITIAL QDate(2000, 1, 1) in qdatetime_p.h

    J2000 is a very very often used astronomical epoch. So if 8000 is 6000 years ahead of 2000, I use -4000 which is 6000 years before 2000. There is much sense here.

    Negative years and years before 1752 (or 1582) are also important for astronomical calculations. We would like to use QDateTime for astronomical calculations.

    Both. By removing the Trolltech copyright you have violated GPL licence.
    OK sorry. Was not clear. I will fix it.
    Penguin #395953 using Qt for open-source development on X11 using C++ and
    Python via PyQt

  4. #4
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    5,372
    Thanks
    28
    Thanked 976 Times in 912 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

    Default Re: Extending QDate, QTime and QDateTime

    Quote Originally Posted by jamadagni
    1582 was the original year of promulgation. See the Wikipedia article. There is no reason why the year of adoption of the calendar in *England* should be used. Why not in another country.
    If somebody has British locale set, then I would expect that 1582-10-11 would be a valid date, while with Polish locale it should be invalid. Also I would expect that daysTo() would take into account those missing days.

  5. #5
    Join Date
    Jan 2006
    Location
    11 N 78 E
    Posts
    110
    Thanks
    10
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    Unix/X11

    Default Re: Extending QDate, QTime and QDateTime

    Quote Originally Posted by jacek
    If somebody has British locale set, then I would expect that 1582-10-11 would be a valid date, while with Polish locale it should be invalid.
    No. There also exists the proleptic Gregorian calendar which extends the Gregorian calendar theoretically before its date of creation. This is heavily used by astronomers. (KStars however uses the Julian calendar before 1582-10-15 on the Gregorian. Try finding in KStars Calculator the spring equinox for 1582 and then for 1583.)
    Also I would expect that daysTo() would take into account those missing days.
    This is not a problem. The number of days from 1582-10-04 on the Julian calendar to 1582-10-15 on the Gregorian calendar is one, and not undefined, but you would be committing the error of mixing calendar systems. The number of days from 1582-10-04 to 1582-10-15 on the proleptic Gregorian calendar is 11, where 1582-10-04 on the proleptic Gregorian calendar would be 1582-09-2x on the Julian Calendar.
    Penguin #395953 using Qt for open-source development on X11 using C++ and
    Python via PyQt

  6. #6
    Join Date
    Jan 2006
    Location
    11 N 78 E
    Posts
    110
    Thanks
    10
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    Unix/X11

    Default Re: Extending QDate, QTime and QDateTime

    Am trying another approach. I will modify the qdatetime.cpp qdatetime.h qdatetime_p.h files only and introduce them into the 4.11 source and compile and install it.

    See the licence notice at the top of the files to see what has been changed.

    One problem: handling negative years while converting to and from strings is going to be a problem. So wherever you find 1752 in the source file has not yet been converted. Your help in fixing the string conversion is most appreciated.
    Attached Files Attached Files
    Penguin #395953 using Qt for open-source development on X11 using C++ and
    Python via PyQt

  7. #7
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    5,372
    Thanks
    28
    Thanked 976 Times in 912 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

    Default Re: Extending QDate, QTime and QDateTime

    Quote Originally Posted by jamadagni
    proleptic Gregorian [...] Gregorian [...] Julian [...] Gregorian [...] Julian [...] Gregorian [...] proleptic Gregorian [...] proleptic Gregorian [...] Julian
    So which one of those three your modified QDateTime uses?

  8. #8
    Join Date
    Jan 2006
    Location
    11 N 78 E
    Posts
    110
    Thanks
    10
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    Unix/X11

    Default Re: Extending QDate, QTime and QDateTime

    Quote Originally Posted by jacek
    So which one of those three your modified QDateTime uses?
    So you have evidently not understood what proleptic Gregorian is. It is not a separate calendar. "proleptic" is intended to mean "extended backwards". It is the same as the Gregorian calendar which we are all using today extended backwards before its date of "creation" on 1582-10-15. My modified class uses the Gregorian calendar, same as the current class. Only, it allows for storage of dates before 1752.
    Penguin #395953 using Qt for open-source development on X11 using C++ and
    Python via PyQt

  9. #9
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    5,372
    Thanks
    28
    Thanked 976 Times in 912 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

    Default Re: Extending QDate, QTime and QDateTime

    Quote Originally Posted by jamadagni
    So you have evidently not understood what proleptic Gregorian is. It is not a separate calendar. "proleptic" is intended to mean "extended backwards".
    So why do you distinguish between Gegorian calendar and proleptic Gregorian calendar if it is the same thing?

    I guess that there should be something like a "local calendar" that would handle the transition from Julian to Gregorian calendar in locale-dependent manner.

    Maybe instead altering Qt sources, that might cause problems when somebody mixes modified and original Qt libraries, you should design your own library that would provide more general date & time handling classes for Qt applications?

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.