我正在构建一个允许用户指定他/她的工作时间的系统。它存储在数据库中：
此信息与用户A相关，因此基于他的时区。用户在他/她的个人资料中选择的内容，例如（UTC + 00:00）都柏林，爱丁堡，里斯本，伦敦
我想要实现的目标是什么？
我需要的？
有人可以为此提供合适的解决方案，因为用户A和用户B可以有不同的时区吗？
在你的问题评论中，你说：
我目前的解决方案是将用户A的工作时间存储为一周中每一天的开始和结束时间。我还存储用户TimeZone。目前，API将使用工作人员TimeZone将工作时间作为JSON Payload返回。然后，我为用户B显示此数据，并使用客户端JS使用用户B TimeZone偏移执行调整。当用户B决定预订时，使用用户A TimeZone设置完成返回API的请求，然后转换该日期时间值并以UTC格式存储。
除非您说使用用户B的时区偏移执行调整，否则这大部分都不错。
问题是许多时区会根据您所谈论的日期和时间而经历不同的偏移。例如，如果在客户端JS中执行类似new Date().getTimezoneOffset()的操作，则会获得用户的当前偏移量。它不一定适用于相关日期的相同偏移量。更多关于the timezone tag wiki标题“Time Zone！= Offset”的内容。
此外，您继续说回到API的请求是在用户A的时区完成的（这很好），但您然后转换并将时间存储为UTC。在那里要小心 - 你需要保留预定的预约时间。可以知道特定事件的UTC时间可能是什么，但实际上这也可以改变。
举个例子，考虑一下the latest time zone changes that occurred in Morocco。他们计划在2018年10月28日结束夏令时，将时钟从UTC + 1切换回UTC + 0。然而，在2018年10月26日，仅仅两天警告，政府宣布他们将永久停留在UTC + 1并取消夏令时。这些短暂的通知变化很成问题，并且以前曾多次发生在世界各地。几年前我写过a blog post about them，今天仍然非常适用。
因此，如果用户A在摩洛哥，并且您在UTC更改后的某个时间存储了约会，那么由于更改没有发生，他们的约会现在将在本地日历上显示一小时。
在此类事件中，如果您保留了事件的预期本地时间，那么您还可以根据已安装的当前时区数据重新计算UTC时间。短暂的通知更改是非常困难的，但如果有几个月的通知，那么您将有时间应用更新并以编程方式更正事件的时间。如果您只存储了UTC时间，那么您就没有这种能力。
考虑这一点的另一种方式是，虽然UTC始终保持一致的前进（除了在某些情况下闰秒），但人类并没有用这样的术语来思考。如果我说我想在上午10点在某个地方见到你，会议就会与当地时间保持一致 - 无论在那个地方的时间和UTC之间发生什么变化。
相反，基于UTC安排会议是盲目相信的，即不会发生超出当前预测的变化。由于我们无法展望未来，我们真的不应该做出这样的假设。
（再次，如果你想要代码的帮助，请显示你在问题中尝试过的代码。通常在.NET中，一个使用TimeZoneInfo类.Here's an overview on how to use it。）
你可以看一下NodaTime，可能是最适合.NET的时区相关库。使用内置的.Net功能可以实现同样的功能，但是它有一些棘手的罕见问题，因此使用NodaTime更加可靠。