Open ronytigo opened 1 year ago
You're right, this method reads attribute 11 from the WallClockTime object, which is the unix local time. Attribute 6 is the utc unix time, which I think should fix the issue. I don't do a lot with datetime objects in Python, but I think passing the utc timezone when constructing the datetime object should also be done.
If you want to create a PR for this issue, you may and I can help with it, else I'll try to get it fixed soon.
I implemented the fix for this, was simple modification of the get_plc_time method, passing in the time zone like you suggested and using attribute 6. Do you prefer I perform the fix from the main branch? I am new to GitHub but will attempt to do the PR and commit push.
sorry for the late response, targeting master
is fine. I may change it into a dev branch before merging, but don't worry about that. The basic steps would be to fork my repo (the Fork button at the top of the page), then create a branch for this fix, check that branch out in your IDE, make the code changes, commit and push those changes to your new branch, then in github create a new pull request back to my repo targeting the master
branch.
ok i did as you instructed, thanks for the help. pull request pending.
Pre-checks
Description time received ignores the timezone of the plc. For example, the plc timezone is GMT + 3 and the time is set to 8pm, the code will receive 8pm instead of 5pm which is the gmt time. If I go to https://www.epochconverter.com and enter the
microseconds
field I get fromplc.get_plc_time().value['microseconds']
it shows 8pm in GMT and 11pm in local (the correct timestamp should show 5pm in GMT and 8pm in local timezone).Target PLC Rockwell Automation/Allen-Bradley Model: 1756-L83E/B Firmware Revision: 33.11
Code Sample Minimal reproduceable code sample
Additional context