Fix PASTCAST errors and small GUI cleanup

[latwood]

Made it so that the ninja PASTCAST code more properly messages via CPLError() and throw() rather than CPLDebug(), so that the GUI more properly errors out. Also some DateTime message/textBox formatting improvements and some small amount of GUI cleanup.

Still could use some general cleanup to the raw ninja PASTCAST code, but that needs to be a separate pull request to avoid diluting the description of these changes any more.

Fixes #692.

[latwood]

Kay, been doing some digging, into whether I can simplify the variable names even further, to drop the forRange idea. Apparently swapping all instances of local vs forRange does NOT work, using the same dem timeZone as the system/machine timeZone looks good, but when changing the dem timeZone, it looks good at first, but then the edit range vs what is displayed gets off by the time difference. In my case, America/LosAngeles vs America/Denver, it gets off by one hour.

Anyhow, I stumbled onto a new concept, which seems to be the real issue: QDateTime and QDateTimeEdit each have their own timezone handling. So if we store the QDateTime variables as the local form, NOT the forRange form, and then use setTimeZone(timeZone) on the various QDateTime widgets, we should stop having these problems.
Example:

ui->pastcastStartDateTimeEdit->setTimeZone(timeZone);
ui->pastcastEndDateTimeEdit->setTimeZone(timeZone);

I suspect that our current setup, even though it looks good right now, if run on a PC in a different timeZone, would then also be off by the time difference. Probably can test this by manually changing the system timeZone of the PC? Depends on how that propagates to Qt.

Just a reminder of what the forRange form is vs the local form. The local form turns out to be the dem timeZone form. The forRange form turns out to be this quirky storing of local QDateTime objects in the machine local timeZone, it offsets the stored time by the time difference between the system/machine timeZone and the dem timeZone.

[masonwillman]

I'm having trouble understanding your comment, so let me see if I have the main points.

• Local vs for range. Local is the time in the timeZone specified on the surface input page. For range is the time used to set the range for the dateTimeEdits. These are variables that we defined and discussed have a specific purpose, so I don't understand the "forRange form turns out to be this quirky storing of local QDateTime objects in the machine local timeZone".
• QDateTime and QDateTimeEdits do not share the timeZone information. This causes problems when trying to set the ranges in different timeZones.

If you have a fix, I would commit it to the PR and allow me to review. It would help to a reference to the code.

[masonwillman]

We need to continue to address issues for the release. Let's not spend more time on this than necessary. If more clean up is needed with variable names, that can be completed later.

[latwood]

Just pushed the fix, and it appears to be working nicely. Turns out this relates to the time zone discussion in issue #637, and directly works to do a more proper fix to issues #705 and #704.

local vs forRange. For example, if your dem is MST, and your machine/system timezone is MST, then 12:00 MST is both the display and allowed range of values in the display. BUT, if your dem is MST, and your machine/system timezone is PST, then 11:00 PST shows up as the display, but the range of values in the display would let you only go to 12:00 PST. Stuff like this when using the forRange variable, it is literally converting local time to the machine/system timezone time.

So, if QDateTimeEdits does not have a timezone set, then it uses the default machine/system timezone, hence the need to convert our local QDateTime into machine/system timezone. Setting the dem timezone to both the QDateTime and the QDateTimeEdit widgets properly now displays without quirky in between machine/system timezones.

[latwood]

Man, I wish I were better at describing this. Anyhow, to clarify, I didn't realize that forRange was simply just machineLocal when I made that variable name. I think the reason the old method worked, was because the QDateTimeEdit widgets were left as the default system/machine timeZone, and so the forRange/machineLocal QDateTime were used to make the times display and match properly. Now, it is a similar idea, just fewer steps, specify the QDateTime and the QDateTimeEdit widgets to use the dem local timeZone. Anything else would lead to a mismatch.

Talking to Mason, he mentioned that he had tried this method out before, and it didn't work. It is possible that using a later version of Qt6 might also have made this work where it wasn't before, not just a mismatch of local vs machineLocal between the QDateTime and the QDateTimeEdit widgets.