Readiing Melsec-Q time from Windows client (is this possible)

Hello to Mitsubishi experts.
I will probably be tasked with configuring the Mitsubishi Electric "MELSOFT MX Sheet (SW2DNC-SHEETSET-J)" utility for a processed food manufacturer who uses Melsec-Q. This utility runs on Windows 10 system and using the Mitsubishi Electric communication component (MX Component) over Ethernet, which permits access to the processors' registers, and trough some simple configuration it is possible to log data on MS Excel worksheets.
The idea is not to have to change anything on the PLC program nor the HMI, as this will add engineering costs from the machine vendor which not a local company. I need to register the time at which the triggers get activated, and the simple way is to use the Windows 10 system time. But if possible, I would like to get the time from the Melsec Q processor. So here is my question: Does the Melsec Q store the sytstem time on some system variable that can be accessed externally through a Melsec client such as MX Component, to get the time to the Windows system? Thanks.

SD 210 to SD 213 are the clock registers See page 535 > of this manual
https://dl.mitsubishielectric.com/dl/fa/document/manual/plc/sh080483eng/sh080483engav.pdf
These contain the date/time registers, note: you may have to update the Date/time with the SET clock function in on-line mode, you can also update from your server I think you could read/write write the decimal values directly to or from the SD registers or there are some functions in GXWorks to read/write date/time to from these registers into standard "D" registers that can also be read/written to via MX component.

Hello parky, thanks very much or this manual and for your thoughts. I must have a problem with my processor or I may be doing something wrong. I cannot set the time on this processor. Mind you, I bought this used in an online auction, but so far has served me well. The attached screenshot shows what I am doing. Would be so grateful if you can spot my mistake.
One piece of good news: SD registers seem to be accessible to Melsec TCP clients such as Softing's dataFEED, which means there is no need to modify the GXWorks2 program to copy such data to normal application D registers. If a third-party Melsec client can access this data, MX Component should as well.

parky, I just called Mitsubishi and showed them how ignorant of Melsec CPU I am, but got my answer. It is necessary to set the SM213 relay (clock data read request) on.

I just realized something very shocking and confirmed with Mitsubishi tech support desk.
The values above:
SD210: 2012h, SD211: 2314h, SD212: 0226h
actually mean: Year 20 (dec, for 2020) Month: 12 (dec), Day: 23 (dec), Hour: 14 (dec), Minutes 16 (dec)!
That means you can understand the time only if you see it in HEX but interpret the values of octets as they were decimal values!!!

So if you are reading from some third-party Melsec TCP client these system registers, you have to convert anything greater than 0Ah appropriately. I called again to Mitsubishi support desk and explained the person my reasoning and this person said, "yes, that's the way it is." I do not have GOT to verify this, but it is likely that the GOT would do these conversions transparently, but I am shocked that this system variable was designed purposefully in this way. I mean, anybody can figure out that the 23rd of the month at 2 in the afternoon would be 170Eh, but go figure, this is 2314h in Melsec universe.

Yes that is correct I must admit I forgot about SM213, It is in hex but the normal way is to use the DATERD Function and this converts it into a date you can read directly so DATERD, D100 will populate the registers D100 to D106 with the following
D100 = 2020 Year
D101 = 12 Month
D102 = 24 Date
D103 = 9 Hr
D104 = 14 Min
D105 = 56 Sec
D106 = 4 Day of week 1-7 (4 = Thurs)
You have a choice you either convert it after a read via the OPC somehow or you add a call to DATERD (it requires an enable so use SM400 always true bit)
To convert it & read those registers, not sure how accurate the PLC clock is but I have always sent back the PC or server time then in the PLC update it every 24 hours with DATEWR.

In my experience, admittedly not so much the Q series, the time clocks are not accurate.
They are almost unusable unless you have a way of regularly updating the time.

I once set up 20 identical machines to open an air valve to blow off excess water in the air lines half an hour before the morning shift started. Within 6 months they were actuating during the shift - and not all together, each one varied.
NB: I had to fit digital timeclocks in the end.

That was my experience, that is why I always update the PLC clock with either the HMI time that can be altered & is usually more accurate or from the Scada system.
So if you do not want to alter the PLC code then the only way would to use the PC time, however, although the time might be a few hundred ms out compared to the actual time the data changed in the PLC due to coms, would it matter that much.

Thanks very much to Ronnie Sullivan and parky for these very important insights. In my particular case, I only need to get the time at which the triggers get activated, which is when the production lot is completed, and this happens a few times per shift. So I will use the PC time as my application does not need that much accuracy. But the information you have provided may be valuable for future projects.