DateTime format or coding - date

Question

i have 3 parameters with date/time and status of phases of electricity meter:
28.11.2019 4:18 - all phases have power
28.11.2019 4:18 - all phases don't have power
28.11.2019 4:23 - all phases don't have power
But these data coded to hex like this:
FA 22 7C 27 07 FF E1
49 22 7C 27 07 08 F3
4E 22 7C 27 00 08 1D
And i don't know how it was did? I mean maybe there is some method to keep and transfer date/time or what?
34 [48 83 27] 07 C6 EA - 3.12.2019 09:01, </b>
38 [48 83 27] 00 E7 74 - 3.12.2019 09:01, </b>
89 [49 83 27] 07 10 38 - 3.12.2019 09:12, </b>
8E [49 83 27] 00 10 D6 - 3.12.2019 09:12, </b>
0E [4B 83 27] 07 21 EA - 3.12.2019 09:24, </b>
13 [4B 83 27] 00 42 74 - 3.12.2019 09:24,</b>
19 [4B 83 27] 07 63 2A - 3.12.2019 09:24,</b>
1D [4B 83 27] 00 63 A4 - 3.12.2019 09:24,</b>
21 [4B 83 27] 07 84 5A - 3.12.2019 09:25,</b>
25 [4B 83 27] 00 84 D4 - 3.12.2019 09:25,</b>
square brackets - i guess it's date. 4th byte is state of phases. I mean low halfbyte(or semibyte?) of 4th byte. 0x7(0b0111) - all phases have power, 0x0(0b0000) - al phases doesn't have power.

Answer 1

TL;DR: The first 4 bytes of each line is a little-endian count of time units since some epoch that is either January 1 or January 6, 1980.
Each timestamp is 4 bytes. When we look at the third last and the second last line, they both have 4B 83 27 within the square brackets that you have put, yet the time changes fro 9:24 to 9:25. The times are obviously truncated, there needs not be more than a second or two between them, but they are not the same. The solution I found was to include the byte before the square bracket in the timestamp.
Timestamps are little endian. The byte before the square bracket varies the fastest as time moves. The next byte varies a little. The remaining two bytes stay constant within the 24 minutes range you are giving. The obvious explanation is that 34 48 83 27 really means 0x27834834, that is, the bytes are reversed.
It took some experimentation, but two common epochs would fit:
January 1, 1980. In this case the time unit used for counting the time since the epoch is around 1 900 440 700 nanoseconds.
January 6 the same year. In this case the unit must be a little smaller, around 1 899 789 030 nanoseconds.
Both January 1 and January 6, 1980 are commonly used epochs. See the link at the bottom for documentation.
I have searched somewhat for an explanation for the size of the unit. Could it be some nice fraction of a second or of a day, for example? I haven’t found any reasonable explanation. I am probably missing something.
I have ignored the issue of time zone and UTC offset. The epoch is likely defined in UTC, and if the times given in the question are in your local time zone, for example, this adds a slight inaccuracy to my analysis.
In code
To convert from hex number to date and time we may use a simple method like the following in Java.
private static LocalDateTime epoch = LocalDateTime.of(1980, Month.JANUARY, 6, 0, 0);
private static int nanosPerUnit = 1_899_789_030;
private static LocalDateTime convert(int n) {
return epoch.plusNanos((long) n * (long) nanosPerUnit);
}
Demonstration:
int[] numbers = {
0x27834834,
0x27834838,
0x27834989,
0x2783498e,
0x27834b0e,
0x27834b13,
0x27834b19,
0x27834b1d,
0x27834b21,
0x27834b25
};
for (int n : numbers) {
System.out.format("%x %s%n", n, convert(n));
}
Output:
27834834 2019-12-03T09:01:20.396289720
27834838 2019-12-03T09:01:27.995445840
27834989 2019-12-03T09:12:08.224348950
2783498e 2019-12-03T09:12:17.723294100
27834b0e 2019-12-03T09:24:27.242281620
27834b13 2019-12-03T09:24:36.741226770
27834b19 2019-12-03T09:24:48.139960950
27834b1d 2019-12-03T09:24:55.739117070
27834b21 2019-12-03T09:25:03.338273190
27834b25 2019-12-03T09:25:10.937429310
The dates and times agree with those from the question. I leave it to you to insert January 1 and 1_900_440_700 nanoseconds and see that this too gives results that agree with the question.
Links
Endianness on Wikipedia
Epoch (computing) on Wikipedia