value of wxDateTime variable changes with commands like "print('check')"

When my script executes commands like "print(‘check’), the value of my wxDateTime changes. I can watch this happen while using PyCharm debug to view the variable. Problems also occur when I run the code from the terminal.

I’ve run both the mini-program provided here, and my whole project three ways:

  1. from the terminal,
  2. from PyCharm with Run
  3. from PyCharm with Debug.
    The following files are attached for you:

Crazy dates log.docx – all three runs of the mini-program with the code at the end.

Whole program output.docx – output from all three runs of the whole program.

           You will see that the console output from the terminal and PyCharm Run are the same, while the Debug shows that the dates have unexpectedly changed between the end and start of the loop.
           Oddly, you will also see that the date used for the output is completely different from any of the dates shown in the consoles. It was expected to be 01/01/01.

           So there seems to be a problem with the output regardless of which way I run the program, but PyCharm Debug is the only way to see anything wrong during the run.

I hope you have some ideas for me.

Thanks.

crazy dates log.docx (21.1 KB)

whole program output.docx (15.3 KB)

New information: ---------------------------------------------

This may be a problem with the wx.lib.masked.timectrl. Apparently it resets the date value to Jan 1, 1970

  • GetWxDateTime(value=None)
  • When called without arguments, retrieves the value of the control, and applies it to the wxDateTimeFromHMS() constructor, and returns the resulting value. The date portion will always be set to Jan 1, 1970. This form is the same as GetValue(as_wxDateTime=True). GetWxDateTime can also be called with any of the other valid time formats settable with SetValue, to regularize it to a single wxDateTime form. The function will raise ValueError on an unconvertable argument.
    Removing references to the time does seem to fix the problem.
···

On Wednesday, April 26, 2017 at 3:16:10 AM UTC-4, Lori wrote:

When my script executes commands like "print(‘check’), the value of my wxDateTime changes. I can watch this happen while using PyCharm debug to view the variable. Problems also occur when I run the code from the terminal.

I’ve run both the mini-program provided here, and my whole project three ways:

  1. from the terminal,
  2. from PyCharm with Run
  3. from PyCharm with Debug.
    The following files are attached for you:

Crazy dates log.docx – all three runs of the mini-program with the code at the end.

Whole program output.docx – output from all three runs of the whole program.

           You will see that the console output from the terminal and PyCharm Run are the same, while the Debug shows that the dates have unexpectedly changed between the end and start of the loop.
           Oddly, you will also see that the date used for the output is completely different from any of the dates shown in the consoles. It was expected to be 01/01/01.

           So there seems to be a problem with the output regardless of which way I run the program, but PyCharm Debug is the only way to see anything wrong during the run.

I hope you have some ideas for me.

Thanks.

Lori wrote:

When my script executes commands like "print('check'), the value of my
wxDateTime changes. I can watch this happen while using PyCharm debug
to view the variable. Problems also occur when I run the code from
the terminal.
...
You will see that the console output from the terminal and PyCharm Run
are the same, while the Debug shows that the dates have unexpectedly
changed between the end and start of the loop.
Oddly, you will also see that the date used for the output is
completely different from any of the dates shown in the consoles. It
was expected to be 01/01/01.

So there seems to be a problem with the output regardless of which way
I run the program, but PyCharm Debug is the only way to see anything
wrong during the run.

Debuggers are not omniscient. They do the best they can to show you
your state, but especially when you're working at the Python/C border,
sometimes things go awry.

I couldn't see anything strange in your console output, but in any case
it's not clear we can do anything without your source code.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.