Powershell: How to get DateTimeOffset from DateTime object when importing a CliXml file

[tloveland1]

I have a script that collects a lot of data from remote machines in different time zones. I serialize all of the data using Export-CliXml, and then deserialize the data using Import-CliXml to parse it into a SQL database.

I'd like to be able to convert the DateTime objects I collect into DateTimeOffset objects, in order to store the DateTime in the machine's local time. Unfortunately, it looks like the offset information is lost during the deserialization. I know I could get the content of the CliXml file and convert the string to a DateTimeOffset, but I'm wondering if there's any way to preserve the information when using Import-CliXml. I know I could also use Get-TimeZone to get the offset information, but I'm wondering if there's a way I can do this without collecting it.

Thank you!

Example: Converting string from CliXml file to DateTimeOffset

Example: Importing CliXml and converting to DateTimeOffset does not preserve TimeZone offset

[sramesh621]

Can you please explain this issue a little more clearly???

In the original XML file, the date is stored in UTC time, so the time is displayed as 13:13 with an offset of 0.

After the import, the date is stored in Central Time with an offset of -5 hrs. That's why it is showing up as 8:13.

[tloveland1]

I want to preserve the offset of the DateTime as it's stored in the XML file, so I can convert the DateTime back to the local time it was created.

The offset is stored in the XML file, and I can grab the string out of the XML file's contents and convert it to a DateTimeOffset to get that local time with the correct offset. When I use Import-CliXml though, the offset is lost during the deserialization back to DateTime, and gets automatically converted to my machine's local time.

I sort of expected the answer to be "get the timezone offset and calculate the local time", but I was hoping there might be some way to preserve the offset during deserialization without needing to collect it.

[vexx32]

Not within DateTime's type structure, no. It's not designed for it. Had it been originally stored as DateTimeOffset, I think this might be possible, however. 🤔

[tloveland1]

Here's a different example using Alaska time (-8):

Manual conversion of the string:

Importing the CliXml

I'm probably just going to end up collecting it as a DateTimeOffset. I was just hoping I didn't have to :)

[vexx32]

Yes, if you initially convert to [datetimeoffset] and serialize that you will retain the information.

@tloveland1 was serializing [datetime] and attempting to rehydrate it as [datetimeoffset] in order to maintain the offset information as it isn't really possibly to instantiate [datetime] with a specified offset.