[Suggestions] Suggest UTC Now as standard Time Format, confused by logging times atm

[RGrabichler]

In the Issues #519 ]New-Feature] Extended Diagnostics in Blazor, i tinker around with the TcoMessages, i i noticed a TimeStamp Issue.

this is Timestamp logged in Console

this is the Timestamp in the Plc

this is my local Timestamp in Germany and Summertime

this is UTC

And this is a complete mess in my opinion.

I would suggest, to allways log in UTC, and everybody can display whatever he wants.

I only assume, the 15.50 timestamp comes from local Slovenia Time? UTC+2 ? In difference to Berlin +1 ?

So in my opinion, the Logger should use per default UtcNow, the Connector should use UtcNow, and
the Wpf or Blazor View can render whatever they want for the User, probably Utc with corresponding TimeZone.

[PTKu]

There should not be a time difference between the time zones you mention.

@TomKovac?

@RGrabichler could you check that you call time synch in your program for the context? Something like this:
https://github.com/TcOpenGroup/tcopen-app-templates/blob/ec2b13f96b091538887fa9851f5fe3d3adfcdeec/templates/mts-s-template/t/src/x_template_x-xae/x_template_xPlc/Technology/Technology.TcPOU#L109C1-L109C29

[RGrabichler]

i call this here

this is the _rtc

But this is the logged message,
Timestamp in [ ] is my local Timezone Timestamp Utc+1, in the Payload it is Utc+3

[PTKu]

You're right. It should be aligned... will have a look on Monday.

[PTKu]

/cib

[github-actions]

Branch 639-_Suggestions_Suggest_UTC_Now_as_standard_Time_Format_confused_by_logging_times_atm created!

[PTKu]

We are unable to reproduce.
@RGrabichler, what are the region settings of your PLC (time-zone)?

[RGrabichler]

for me it is UTC+1, Berlin Time.

[PTKu]

Same as me! 😊
Where do you run your Blazor server? Is it on the PLC, or is it hosted elsewhere? It appears that there might be a difference in the environment settings between where you run your server and the PLC.

You can try running it with the second argument, specifying the AMS ID of your server as follows: app.RtcSynchronize(TRUE, 'YOUR_SERVER_AMS_ID', 60) (An empty string indicates that it will synchronize with the local system).

[RGrabichler]

ok, in this specific scenario, where i tinker with the Diagnosis Component, i use UmRT and blazor runs on local Dev Pc/
So presumably both run on UTC +1.

[PTKu]

It looks like that might be an issue with UmRT.
Did you try:

You can try running it with the second argument, specifying the AMS ID of your server as follows: app.RtcSynchronize(TRUE, 'YOUR_SERVER_AMS_ID', 60) (An empty string indicates that it will synchronize with the local system).

?

[RGrabichler]

i tried, and i tried it with real hardware.
both have identical time settings



this is AMS ID from dev PC, were i run the Blazor App atm

[PTKu]

@TomKovac any comment on this?

@RGrabichler sorry if you answered this question before, but what would be your correct local time in the example above?

@peterbarancek what time do we set to the TimeStamp in the messenger?

[peterbarancek]

"This is my output. I am running an app on my laptop. The time is synchronized with the PLC (as seen in the screenshot at the bottom right of the picture). It runs on .net48 and is a WPF application. In my opinion, the time difference might be due to using .net5 or Blazor..."

[RGrabichler]

@TomKovac any comment on this?

@RGrabichler sorry if you answered this question before, but what would be your correct local time in the example above?

@peterbarancek what time do we set to the TimeStamp in the messenger?

in this case, 21.44 was the right time.

[RGrabichler]

i tried a bit


this is the ams ID from the PLC, manually changed the Clock to differ from real Time, to test it out.

This is my Dev PC

but this is not working, what am i doing wrong?
Time shows still Plc Time, even when i am setting AMS ID to Dev PC, where Blazor runs.

[PTKu]

@RGrabichler, the update rate is currently set to 60 seconds. If needed, you can modify the second parameter to decrease this rate.

Regarding the original issue, we've pinpointed the cause of the time discrepancy. Connector.NET5 utilizes a newer ADS driver that considers the time zone. Given that the PLC time is designated as UTC, when a value is read from the controller, it's adjusted to local time.

Regrettably, we don't have a straightforward solution for this predicament at the moment. Addressing it would necessitate modifications in the Inxton connector. Please note that this connector is in its experimental phase and isn't officially supported for a .NET 5 target. While we don't have immediate plans, we may consider making the necessary adjustments in future major Inxton releases, especially those after the TwinCAT 4026 launch.

[RGrabichler]

ok, im fine with that and can implement a workaround with manually adding or subracting hours :X
thanks for the effort