I’ve poked around something like this before, without a lot of success, but learnt a little
Importantly, what gets held in a DateTime Item state is not always UTC but rather whatever you told it to be … with a timezone ID. If you don’t supply a timezone, it assumes default as your local.
I think this is significant. “millis” here is “Unix Epoch” format. There is no timezone in that form, everything is always in UTC.
So joda’s now.millis gives you now in a UTC.
When openHAB postUpdate parses millis into a DateTime, it also knows you must mean UTC and adds that zone to the DateTime.
2020-10-15 23:01:25.985 [INFO ] [.eclipse.smarthome.model.script.test] - posting string 2020-10-15T23:01:25.983+01:00
2020-10-15 23:01:26.088 [INFO ] [.eclipse.smarthome.model.script.test] - state from string 2020-10-15T23:01:25.985+0100
2020-10-15 23:01:26.090 [INFO ] [.eclipse.smarthome.model.script.test] - posting millis 1602799286089
2020-10-15 23:01:26.192 [INFO ] [.eclipse.smarthome.model.script.test] - state from millis 2020-10-15T22:01:26.091+0000
Note the stringy now includes my timezone.
The millis now is corrected for my timezone, but expressed in UTC.
Both these are the same time of course, but if you string-format the hours from stringy-now you’ll get 23, and from millis-now you’ll get 22
So the moral is …
Yes, that is what you loaded your Item with.
To get that back into a local zone is going to take more than just a format, I think.
The internal openHAB code that prepares a DateTime for display in a UI seems to be clever enough to convert everything properly to local timezone (whether you want that or not!), but I do not think that is available to you in rules. You’d have to make your own.