Evidence项目中日期格式化时区问题的解决方案

问题背景

在使用Evidence项目进行数据可视化时，开发人员经常需要展示带有时间戳的数据。默认情况下，Evidence会使用UTC时间格式显示时间戳，但实际业务场景中，用户往往更希望看到本地时区或特定时区的时间显示。

问题现象

当开发人员尝试在Value组件中使用fmt="hms AEST"这样的格式字符串来显示澳大利亚东部标准时间时，虽然页面渲染结果正确，但在执行npm run build命令时会遇到错误提示："Unexpected error applying formatting Error: unrecognized character T in hms AEST"。

问题原因

这个问题的根本原因在于Evidence项目采用了类似Excel的日期格式规范。在这种规范中：

1. 格式字符串中的普通字符（如h、m、s等）会被解析为日期时间格式代码
2. 如果需要显示字面意义的文本（如时区名称AEST），必须使用双引号将其括起来
3. 当格式字符串本身使用双引号包裹时，内部的双引号需要进行转义

解决方案

正确的格式字符串写法应该是：

<Value data={last_task_timestamp} column=max_task_timestamp fmt='hms "AEST"'/>

关键点说明：

1. 整个格式字符串使用单引号包裹
2. 时区名称"AEST"使用双引号包裹
3. 这种写法既保证了构建过程不会报错，又能正确显示带有时区的时间格式

扩展知识

Evidence项目支持多种日期时间格式代码，常用的包括：

• yyyy：四位数的年份
• yy：两位数的年份
• mm：两位数的月份
• dd：两位数的日期
• hh：两位数的小时（12小时制）
• HH：两位数的小时（24小时制）
• mm：两位数的分钟
• ss：两位数的秒数
• AM/PM：上午/下午标记

对于需要显示固定文本的情况，都应该使用双引号将其括起来，例如：

<Value fmt='"Date: "yyyy-mm-dd'/>

最佳实践建议

1. 对于需要显示时区的时间格式，始终使用双引号包裹时区名称
2. 优先使用单引号包裹整个格式字符串，以避免双引号嵌套带来的转义问题
3. 在开发过程中及时执行构建命令，尽早发现格式字符串问题
4. 考虑将常用的时间格式定义为变量或常量，提高代码可维护性

通过遵循这些规范，开发人员可以避免构建错误，同时为用户提供符合业务需求的时间显示格式。