正确安装需使用完整包名 robmckenzie/php-timezone-converter 并显式指定 @dev 版本；传入时区必须为 IANA 标准格式，转换前需校验；convert() 需明确指定源时区，避免将本地时间误作 UTC 处理。
Composer 安装 php-timezone-converter 失败或找不到包？
这个库官方名称是 robmckenzie/php-timezone-converter，不是 php-timezone-converter —— 直接搜后者会找不到。Composer 默认不启用非稳定版本，而该库最新版仍是 dev-master 或 v0.2.0@dev，必须显式允许 dev 稳定性。
- 运行
composer require robmckenzie/php-timezone-converter:^0.2.0@dev - 如果项目
minimum-stability设为stable（默认），需在composer.json中临时加："prefer-stable": true并确保"minimum-stability": "dev"，否则安装会报Could not find package - 别用
composer require php-timezone-converter—— 这个包名不存在，会提示Package "php-timezone-converter" listed for update is not installed
构造 TimezoneConverter 实例时抛出 DateTimeZone::__construct(): Unknown or bad timezone
错误通常来自传入了非法时区字符串（如空值、拼写错误、缩写如 EST 或 PST），而该库底层仍依赖 PHP 原生 DateTimeZone。它不自动校验或转换模糊时区标识。
- 用户前端提交的时区应限定为 IANA 标准格式，例如
America/New_York、Asia/Shanghai，而非UTC+8或China Standard Time - 若需支持偏移量输入（如
+08:00），得先映射到 IANA 时区：可用timezone_name_from_abbr('', $offset * 3600, 0)辅助，但注意该函数对夏令时处理不可靠，生产环境建议用League\ISO3166或用户选择下拉菜单约束输入 - 实例化前务必用
in_array($tz, DateTimeZone::listIdentifiers())校验，避免直接传入用户原始输入
用 convert() 转换时间却返回原时间，没生效？
convert() 方法默认只做「时区转换」，不改变时间语义；如果你传入的是本地时间（比如用户填写的“今天下午3点”），它不会自动识别为“用户本地时间”，而是当作 UTC 时间再转出——这是最常踩的逻辑坑。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 正确做法：明确指定源时区。例如用户在
Asia/Tokyo填写了2024-05-20 15:00:00，应构造new DateTime('2024-05-20 15:00:00', new DateTimeZone('Asia/Tokyo'))，再传给convert() -
convert()第二个参数是目标时区（string），第三个可选参数是输出格式（默认Y-m-d H:i:s），不要误把格式当目标时区 - 该库不处理历史时区变更（如 1970 年前的 GMT 偏移调整），纯按当前规则计算，对日志归档类场景需额外注意
和 Carbon 混用导致时区行为不一致
Carbon 默认使用系统时区（date_default_timezone_get()），而 php-timezone-converter 所有操作都基于显式传入的 DateTimeZone 对象。两者混用时，若 Carbon 实例未显式设时区，toDateTime() 后再交给 convert() 可能引入隐式转换。
立即学习“PHP免费学习笔记（深入）”；
- 统一入口：所有时间对象创建时强制指定时区，例如
Carbon::createFromFormat('Y-m-d H:i:s', '2024-05-20 15:00:00', 'Asia/Seoul') - 避免链式调用中丢失时区上下文，如
$carbon->tz('UTC')->toDateTime()后再传给convert()，此时toDateTime()返回的是无时区标记的DateTime，容易被误认为本地时间 - 该库不提供 Carbon 集成封装，也不修改全局时区，所以不必担心影响其他组件——但你得自己管好每个时间对象的时区归属
实际业务里，最难的不是调用 convert()，而是确认「这个时间戳到底属于哪个时区上下文」。用户表单提交、数据库存储、API 接收、缓存序列化……每一步都可能悄悄丢掉时区信息。库本身很轻，但时区问题从来不是库能单独解决的。
