如何获取与Joda DateTime后端兼容的完整HTML时区选择器

核心兼容规则 #

要做纯HTML select和Joda后端完全兼容，没有复杂的依赖要求，核心判定逻辑很简单：

• 所有<option>标签的value属性，必须和DateTimeZone.getAvailableIDs()返回的时区标识符字符串完全逐字一致，不能做任何缩写、别名替换、加自定义后缀的操作
• 只要value值完全匹配，后端收到前端传的字符串后，直接用DateTimeZone.forID()就能正常解析，不会抛出无效时区的异常
• Joda的时区ID集合完全遵循IANA时区数据库标准，不存在平台自定义的私有特殊时区条目，和业界通行的时区标准没有偏差

纯HTML select的基础实现结构 #

不需要引入任何前端框架或第三方组件库，直接用原生标签就可以搭建基础组件：

<select name="client_timezone" required>
  <!-- 全量option的value严格对齐后端返回的DateTimeZone可用ID -->
  <option value="UTC">UTC</option>
  <option value="Africa/Cairo">Africa/Cairo</option>
  <option value="America/New_York">America/New_York</option>
  <!-- 此处替换为全量匹配的时区条目 -->
  <option value="Asia/Shanghai">Asia/Shanghai</option>
  <option value="Europe/London">Europe/London</option>
</select>

常见兼容踩坑点 #

• 别直接抄网上流传的静态HTML时区列表用，这类列表大多是多年前的旧版本内容，和当前Joda版本支持的ID集合无法完全匹配，容易出现个别选项后端识别失败的问题
• 别把option的value改成带偏移量的展示文本，比如写(UTC+8) 北京作为value，后端无法直接解析这类自定义格式的字符串
• 想要优化用户选择体验是完全可以的，在option的展示文本里附加当前时区的UTC偏移量信息就行，但value字段必须保留原始的标准时区ID字符串
• 用<optgroup>标签按大洲对时区ID做分组展示也不会影响兼容性，只要不对option的value做修改，分组结构可以根据用户体验需求自由调整

避免前后端版本错配的最优方案 #

手动维护静态的全量时区列表很容易和后端版本脱节，最省心的落地方式是：

• 后端在渲染页面时，直接调用DateTimeZone.getAvailableIDs()拿到排序后的全量ID列表，循环生成select的option条目直接输出到页面
• 这种实现方式下，前端拿到的时区列表永远和后端Joda支持的列表1:1匹配，不需要手动追版本同步列表内容，从根源上杜绝兼容问题

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