Programming dates in Hexadecimal MG ZS LR

[Catsailor]

Trying to decipher the hexadecimal code that should give the programming date for my ZS. The OBDII reports this for the battery charger:

Charger
Boot software fingerprint: CCU "(200
Manufacturer spare part number: G4
System supplier identifier: qw
ECU manufacturing date (ASCII): #
ECU serial number: 973414XP5185336
VIN: LSJW7409XPZ255755
Manufacturer ECU hardware number: G4G
System supplier ECU hardware number: 10231549
System supplier ECU software number: S000R2
Repair shop code or tester serial number: FFFFFFFFFFFFFFFFFFFFFF
ECU manufacturing date (HEX): 230520
Programming date (HEX): 1147344701

If I use a hexadecimal converter it gives the following:

GMT: Friday, August 5, 4321 1:40:17 AM
Your time zone: Friday, August 5, 4321 2:40:17 AM GMT+01:00
Decimal timestamp/epoch: 74209052417

That seems like nonsense. Any suggestions.

 

[fred12345]

GMT: Friday, August 5, 4321 1:40:17 AM
Your time zone: Friday, August 5, 4321 2:40:17 AM GMT+01:00
Decimal timestamp/epoch: 74209052417

Is the date always the same or changes if you try another day?

 

[decrep]

Something very strange there, the manufacturing date is much shorter than the programming date.

 

[Catsailor]

First a word as to why I wanted to do this. I wanted to know if software updates had been applied to, for example, the Battery Managment System or at least the date on which the initial programming had been carried out.

Several oddities in the data recieved via OBDII. The ECU's have a manufacturing date in Hexadecimal that is nearly sequential:

ECU manufacturing date (HEX): 230504

ECU manufacturing date (HEX): 230511

ECU manufacturing date (HEX): 230511

ECU manufacturing date (HEX): 230512

ECU manufacturing date (HEX): 230515

ECU manufacturing date (HEX): 230518

ECU manufacturing date (HEX): 230518

ECU manufacturing date (HEX): 230519

ECU manufacturing date (HEX): 230519

ECU manufacturing date (HEX): 230519

ECU manufacturing date (HEX): 230519

ECU manufacturing date (HEX): 230520

ECU manufacturing date (HEX): 230520

ECU manufacturing date (HEX): 230522

This not true of the ECU Programming dates which are random. Here's a sample:

Programming date (HEX):	Normal Date
GMT: Tuesday, January 17, 4169 4:57:38 PM
GMT: Wednesday, September 3, 4177 12:01:05 PM
GMT: Saturday, May 28, 4191 4:02:09 PM
GMT: Thursday, July 31, 4200 4:33:05 AM
GMT: Monday, June 21, 4224 2:08:01 AM

[td]

1028476802​

[/td]​

[td]

1038814901​

[/td]​

[td]

1052551401​

[/td]​

[td]

1063964501​

[/td]​

[td]

1090862401​

[/td]​

I did wonder if the dates might relate to the Chinese Lunar Year but they don't. Has anyone used an OBD dongle and had the same confusing results? Or is there someone who has more knowledge of Hexadecimal dates than I do (not difficult) got a way of carrying out the conversion that produces a more coherent result.

 

[Catsailor]

First a word as to why I wanted to do this. I wanted to know if software updates had been applied to, for example, the Battery Managment System or at least the date on which the initial programming had been carried out.

Several oddities in the data recieved via OBDII. The ECU's have a manufacturing date in Hexadecimal that is nearly sequential:

ECU manufacturing date (HEX): 230504

ECU manufacturing date (HEX): 230511

ECU manufacturing date (HEX): 230511

ECU manufacturing date (HEX): 230512

ECU manufacturing date (HEX): 230515

ECU manufacturing date (HEX): 230518

ECU manufacturing date (HEX): 230518

ECU manufacturing date (HEX): 230519

ECU manufacturing date (HEX): 230519

ECU manufacturing date (HEX): 230519

ECU manufacturing date (HEX): 230519

ECU manufacturing date (HEX): 230520

ECU manufacturing date (HEX): 230520

ECU manufacturing date (HEX): 230522

This not true of the ECU Programming dates which are random. Here's a sample:

Programming date (HEX):	Normal Date
GMT: Tuesday, January 17, 4169 4:57:38 PM
GMT: Wednesday, September 3, 4177 12:01:05 PM
GMT: Saturday, May 28, 4191 4:02:09 PM
GMT: Thursday, July 31, 4200 4:33:05 AM
GMT: Monday, June 21, 4224 2:08:01 AM

[td]
1028476802

[/td]
[td]
1038814901

[/td]
[td]
1052551401

[/td]
[td]
1063964501

[/td]
[td]
1090862401

[/td]​

I did wonder if the dates might relate to the Chinese Lunar Year but they don't. Has anyone used an OBD dongle and had the same confusing results? Or is there someone who has more knowledge of Hexadecimal dates than I do (not difficult) got a way of carrying out the conversion that produces a more coherent result.

Chat GPT suggests:
Got it! The value 1028476802 you're dealing with is likely a timestamp in a format used by the car's ECU (electronic control unit), which is commonly based on UNIX timestamps or another epoch format. It's common in embedded systems or automotive software.


Let’s break it down:

1. Hexadecimal Date (1028476802) is often a number representing seconds since a specific epoch (usually the Unix epoch: January 1, 1970).
2. You provided the number in hexadecimal, so converting 0x1028476802 (or 1028476802 in hexadecimal) to decimal gives us 432,453,115,138.
3. Now, treating this as a UNIX timestamp, let’s convert it to a western date

This gives date of May 23, 2013 at 5:12:18 AM UTC which can't be correct for an MG ZS

 

[decrep]

Does that mean it's not using 1/1/70 as it's epoch?
Can we guestimate something more reasonable?
Is there a significant Chinese date about 10 years later?

 

[Catsailor]

Further research on Chat GPT:

ChatGPT said:​

When you use an OBD‑II dongle on a UK‑spec MG ZS EV Long Range (2023), if the app returns a value under the Charger / On‑Board Charger module labeled as “Programming date (HEX): 1123784001”, this matches exactly the format reported in community firmware logs—most notably for the MG5 EV — where Charger ECU Programming date (HEX): 1123784001 appears docs.openvehicles.com+2mgevs.com+2mgevs.com+2.

Interpreting “Programming date (HEX) = 1123784001”​

• Based on posts by users decoding similar values, this number is not straightforward human-readable; it's likely a Unix timestamp.
• For instance, 1123784001, when interpreted as a standard Unix epoch (seconds since January 1, 1970 UTC), translates to:

This suggests the firmware image was originally compiled or built on 11 August 2005 mgevs.commgevs.com.

Summary​

• Programming date reported: 1123784001 (HEX field)
• Likely decoded timestamp: 11 August 2005, ~18:13:21 UTC (Unix epoch)
• Meaning: This is likely the build or compile date of the firmware—not the date it was flashed to your vehicle.

---

Important Notes​

• Many OEMs embed firmware build timestamps that reflect when the software package was created—not necessarily when it was deployed to your car's ECU.
• Thus, a 2005 date does not mean your 2023 vehicle was programmed back then; it's almost certainly referencing the firmware baseline.
• Actual flash or update date likely isn’t captured in that hex field—you’d need MG workshop diagnostics or official service logs for that.

 

[fred12345]

Further research on Chat GPT:

ChatGPT said:​

• Based on posts by users decoding similar values, this number is not straightforward human-readable;

I would give up ChatGPT by now ...

 

[Catsailor]

I refuse to give up on humans. But they are so far deaf to my beseeching.