One option would be to do the transformations (both ways) entirely in the client, using JavaScript - there may be some standard libraries for this (I have no idea).

Another option is to do it inside the domain model. Say you have DateDue property. Store this property on the server as UTC, but hide it from the user. Instead display a derived Date property. You'll then need to represent the current
user in the model with details of their timezone, and then look this up when doing the transformation between the real and the derived due date. If you aren't dealing with identified users then this approach isn't an option.

I'm not sure why Naked Objects complicates the issue - given that you say you haven't found any solution on how to solve this for, say, a regular ASP.NET MVC app. My best advice is to post onto a much larger forum dealing with ASP.NET MVC.
If you can figure out how to do it there, then you'll have a startpoint for how to do it on Naked Objects MVC.

The only reason why I say Naked Objects complicates things is because... well, I guess just because I probably haven't separated the concerns in my mind so well yet. :) I agree. I should first figure out how to solve it, before bringing NO into the picture.

Both your approaches sound promising. I will investigate and report back.

Thank you.

PS I think the whole DateTimeOffset typing thing confuses the heck out of me. Haven't yet found an explanation that cleared up the mud for my mind. (Or the mud in my mind)

Can I ask: is it necessary for the clients in the different time-zones to interact with each other, or no?

If they do (eg it is a calendar scheduling system), then it would seem that you would want the server to hold the "canonical" date/time (eg UTC), and then have each client work out what that would be for their own timezone. In the case of NO
MVC, it might be that the rendering of the date/time of an entity would need to be with respect to the timezone of the user making the request. You can certainly find out who the user is that is making the query, so I would imagine there might be a way to
lookup their timezone.

If the clients in different timezones don't interact with each other, then I think you can forget about offsets etc; the fact that client who use a datetime of "21-Dec 9am" are actually referring to different times doesn't matter.

No, the users from different timezones do not have to interact. However, some events that generate a date occur on the server, and need to be displayed to the client appropriately. Similarly, some dates come in over simple web hooks from different timezones,
and those again have to be stored on the server correctly and then displayed to the client correctly.

Yes, I had to abandon my beloved Outlook Express about a year and a half ago when switching to Windows 7. I just could not find a client that worked for me, so starting using GMail exclusively also. I now don't know how I lived without it. It is absolutely
brilliant. And the keyboard shortcuts make everything a snap.