Asp.net Identity：MVC Web应用能否在用户登录/已登录时获取客户端本地时区

完全可以在用户访问站点URL时从浏览器端读取到本地时区信息，原生能力即可覆盖你提出的登录环节、已登录会话环节两个场景，刚好匹配你“会话内存存储、用于UTC时间转本地时间”的核心需求，不需要额外引入第三方组件。

核心采集逻辑 #

浏览器原生提供无需用户交互的时区获取能力，常用的两个取值方式：

• 调用Intl.DateTimeFormat().resolvedOptions().timeZone，直接拿到符合IANA标准的时区标识（比如Asia/Shanghai、Europe/London），现代浏览器全兼容，是目前最可靠的取法
• 调用new Date().getTimezoneOffset()，获取本地时间与UTC的分钟差值，可作为时区值的辅助校验项

分场景接入流程 #

场景1：登录操作环节的时区采集 #

这个阶段用户尚未通过Asp.net Identity的身份校验，没有正式登录态：

• 在全站统一布局页加初始化脚本，用户首次访问任意站点URL时，先判断sessionStorage中是否已经存有时区值，没有就现场执行上面的JS逻辑采集，存入sessionStorage。这是会话级存储，关闭标签页就自动清空，完全匹配“整个应用会话期间留存”的要求
• 登录表单增加隐藏字段，值直接取sessionStorage里存的时区标识，用户提交登录请求时，这个字段会随其他登录参数一起提交到后端
• 后端接收到时区值后，不需要强制写入用户数据库表（除非要做用户长期时区偏好的可选存储），直接存入HttpContext.Session中，这部分是服务端的会话内存存储，后续同一会话的所有请求都可以直接取用，用于UTC时间的本地转换
• 哪怕用户从其他第三方链接直接跳转到登录页，全局布局页的初始化逻辑也会在登录页加载时完成时区采集，不会漏采

场景2：已登录会话的时区采集 #

用户完成Identity认证、进入受授权保护的页面后：

• 全局初始化脚本优先校验两个位置的时区值：一是sessionStorage，二是后端HttpContext.Session，只要任意位置有值就直接沿用
• 如果两个位置都没有时区值（比如用户手动清空了本地存储、会话刚续签），脚本会现场执行采集逻辑，随当前页的AJAX请求把时区值提交给后端，再次存入服务端会话内存
• 你也可以按需选择把这次采集到的时区值同步更新到AspNetUsers表的对应字段，作为用户下次访问时的默认时区兜底，不影响当前会话的内存存储逻辑

实现注意事项 #

• 转换时间时优先用拿到的IANA时区标识，配合后端的TimeZoneInfo.ConvertTimeFromUtc()方法做转换，别偷懒靠手动计算时区偏移量实现转换——很多地区有夏令时切换规则，手动算的偏差会在特定月份出问题，用标准时区标识让系统自动适配规则精度最高
• 不需要把时区值存在永久Cookie里做长期持久化，严格匹配“会话期间存储”需求的话，sessionStorage + 服务端HttpContext.Session的组合是最轻量的实现，也不会造成不同用户的时区数据串扰
• 页面加载时的时区校验逻辑要放在脚本最前面执行，避免第一次页面渲染时出现时间格式错误

内容的提问来源于stack exchange，提问作者user272727