You have to remember that all those Item state values are the same time, just with different zones.
[%1$tH:%1$tM, %1$td.%1$tm.%1$tY]
the java string formatter will always assume your local timezone and display your data converted for that local timezone.
I don’t think it is possible to request [%1$xxx] style formatting in any other timezone. I think you would have to use a transformation, probably JS javascript.
EDIT - This is quite an interesting puzzle really 
I loaded a test DateTime Item with
2020-08-14T13:35:26.815-0600
and using REST API it’s easy enough to confirm that’s exactly how it is held in the Item state, no conversion takes place during update.
If you try sitemap -
Text item=testDate label="test [%s]"
you might expect the %s to give you the “raw string”. But it doesn’t, I will see
2020-08-14T20:35:26.815+0100
it’s auto converted to my own +1 timezone.
This blows up the idea of using javascript transform, if we have a test.js like
(function(inputData) {
var out = inputData ; // allow anything to pass through
return out ; // return a string
})(input)
and use sitemap
Text item=testDate label="test [JS(test.js):%s]"
we get the same unwanted result
2020-08-14T20:35:26.815+0100
which means OH has auto-converted the datetime to my local zone before passing to my javascript. This means there is no way in the transform to find out what the time stored in the Item state actually was.
Of course you can write a transform to take a DateTime state and do its own maths like subtracting 6 hours before passing to display, but this is not the same as reading the stored real datetime.
I can’t think of a clean way to accomplish this, without using String Items and/or proxy Items and rules.