Sure, you can grab the date and time (if your micro has the RTC option), but you have some choices to make. Before making suggestions about data types and format, it might be useful to know where all this information will eventually end up.
In general, you will have a parallel FIFO for the date and one for the time, the same logic as above triggered by the same condition, but unique memory locations.
Once I did something like this on a small PLC that was low on memory so I encoded the time in a list of floats where the month, day and hour was before the decimal point and the minutes and seconds were after the decimal point:
MMDDHH.MMSS
Since I was not sending this data anywhere except my own little HMI (technician access only) screen, it was worthwhile to write the code to formulate that, squeeze it into data tables of floats and display it "normally" on the HMI with some decoding expressions. I needed accuracy down to the second and wanted a list of up to 1000 items to be retained in the SLC so it spanned four data tables. I didn't want to tie up 20 data tables to keep each part of the date and time separated so I wrote a CPT block to take the month * 10,000 + (day * 100) + hour + (minute/100) + (second/10000).
If you have the space (likely with only 24 items recorded), you will have simpler logic if you store the elements of the date and time each in their own files, and just run logic for each element in parallel to your weight recordings and triggered from the same event. It might be a bit wasteful to use a whole INT to store a value that only ranges from 1-12 (month), or 0-59 (minute) but it may be easier to follow in the future and easier to make sense of wherever this data eventually "lands".