Go time.ParseInLocation 兼容多种时间输入

要让 Go time.ParseInLocation 兼容多种时间输入，可以维护一个有限的布局列表，依次尝试，并把默认时区作为显式参数。带数字偏移量的输入保留其时间点含义，无时区输入才按约定地点解释；所有候选都失败时返回错误，不能把零时间当成功结果。

官方地址：https://pkg.go.dev/time

我希望兼容的是三类明确输入

我在设计导入接口时，会先拿一组具体样本约束“兼容”的含义。这里采用一个假设场景：合作方可能发来 2026-10-31T09:15:00+08:00、2026-10-31 09:15:00，也可能只给 2026-10-31。下面是围绕这三类样本作出的设计取舍，不是一次线上事故记录。

我的第一项取舍是只接受已说明的格式。带偏移量的日期时间用于表达时间点；本地日期时间依赖双方约定的默认时区；日期则缺少时分秒，需要业务接受将其解释为当地零点。如果字段实际表示“营业日期”，我会保留日期语义，避免仅为统一类型就把它当作事件时间。

我不会顺手加入 10/11/2026 这种年月日含义不明确的输入。越宽松的候选列表不一定越方便：当多个布局都能成功时，列表顺序实际上变成了业务解释规则。

让格式标签跟随时间一起返回

只返回一个 time.Time 很难看出调用者原来提供了什么。因此，我会让结果包含 Value 和 Format：前者保存解析值，后者记录命中的输入类别。rfc3339、local-datetime、local-date 是这段接口自定义的标签，不是标准库识别出来的格式名称。

这个标签能帮助调用者区分“用户提供了日期”与“用户提供了零点的日期时间”。它不保存原始输入全文，也不保证还原原来的小数位数、偏移量写法或外围空白；需要审计原文时，应在业务数据模型中另存原值。

把默认时区变成显式参数

ParseInLocation 的布局仍使用 Go 参考时间写法，比如 2006-01-02 15:04:05。我会把 loc 作为必填参数：没有时区信息的文本按它解释；输入给出偏移量时，不能把这当成将钟面时间强制套到默认时区的指令。

例如 2026-10-31T01:15:00Z 与 2026-10-31T09:15:00+08:00 表达同一时间点。若界面需要上海时间显示，可以对解析后的值调用 In(loc)；如果要统一输出 UTC，则调用 UTC()。这两者是表示方式调整，与重新解释原始文本不同。

示例用 LoadLocation("Asia/Shanghai") 加载地点，并处理加载失败。我的偏好是在初始化阶段明确报告配置错误，而不是悄悄回退到服务器的 time.Local，使不同部署得到不同结果。

用有限候选实现解析接口

下面的原创示例将候选列表放在函数内部，避免调用方在运行过程中修改格式集合。TrimSpace 是我为本接口选择的输入政策；如果协议要求逐字符精确，应取消这项宽容。函数没有文件或网络资源，无需额外关闭句柄。

package main

import (
    "errors"
    "fmt"
    "strings"
    "time"
)

var ErrUnsupportedTime = errors.New("时间不符合约定格式")

type ParsedInput struct {
    Value  time.Time
    Format string
}

// ParseInput 接受有限格式；默认时区必须由调用方明确传入。
func ParseInput(raw string, loc *time.Location) (ParsedInput, error) {
    if loc == nil {
        return ParsedInput{}, errors.New("默认时区不能为空")
    }
    text := strings.TrimSpace(raw)
    if text == "" {
        return ParsedInput{}, errors.New("时间输入不能为空")
    }
    candidates := []struct {
        name   string
        layout string
    }{
        {"rfc3339", time.RFC3339Nano},
        {"local-datetime", "2006-01-02 15:04:05"},
        {"local-date", "2006-01-02"},
    }
    for _, c := range candidates {
        // 输入含明确偏移量时，偏移量不会被默认时区覆盖。
        value, err := time.ParseInLocation(c.layout, text, loc)
        if err == nil {
            return ParsedInput{Value: value, Format: c.name}, nil
        }
    }
    // 不返回零时间伪装成功；调用方可用 errors.Is 判断错误类别。
    return ParsedInput{}, fmt.Errorf("%w：支持 RFC3339、本地日期时间或日期",
        ErrUnsupportedTime)
}

func main() {
    loc, err := time.LoadLocation("Asia/Shanghai")
    if err != nil {
        // 启动时发现时区数据不可用就停止，不降级为服务器本地时区。
        fmt.Println("加载默认时区失败:", err)
        return
    }
    inputs := []string{
        "2026-10-31T09:15:00+08:00",
        "2026-10-31T01:15:00Z",
        "2026-10-31 09:15:00",
        "2026-10-31",
        "31/10/2026",
    }
    for _, raw := range inputs {
        parsed, err := ParseInput(raw, loc)
        if err != nil {
            fmt.Printf("输入 %q 被拒绝: %v\n", raw, err)
            continue
        }
        // UTC 用于统一展示时间点，Format 保留匹配的输入类别。
        fmt.Printf("%q format=%s utc=%s\n", raw, parsed.Format,
            parsed.Value.UTC().Format(time.RFC3339Nano))
    }
}

上面的代码是供读者使用的完整示例，没有在本文中执行；下面列的是依据接口设计得到的预期。前三条日期时间样本在指定上海默认时区后，均对应 2026-10-31T01:15:00Z，但匹配标签不完全相同。

失败时保留输入含义而非猜测

我选择用 ErrUnsupportedTime 表示所有候选都不匹配，而不是把最后一次尝试的 ParseError 原样暴露给用户。最后一次失败仅代表某个布局不匹配，不一定最能解释整段输入的问题。若内部诊断需要细节，可以按布局保留失败原因，但对外错误仍应说明支持范围。

空输入与空地点在本例中分别返回明确错误；它们没有包装成 ErrUnsupportedTime。调用方应先检查 err，成功后再读取 Value，不能通过零时间自行推断是否失败。需要稳定区分所有错误类别的 SDK，可以继续定义独立错误值或错误类型。

还有一个容易低估的细节：Go 的时间解析器在秒字段后可以接受小数秒，即使布局没有显式写出它。这里的本地日期时间布局因此不是一个“只能精确到秒”的严格文本校验器。如果业务禁止小数秒、限制长度或要求固定字符位置，应另行明确这些词法约束，而不是仅靠候选布局名称作承诺。

哪些输入值得另开协议

这套接口适合已知上游只存在少量历史格式的导入任务。若我可以控制新接口，会优先让上游统一发送带偏移量的日期时间；旧格式留在一个范围明确的兼容层，并通过 Format 观察其使用情况。

Unix 时间戳能否直接加进来？需要先明确秒、毫秒还是微秒。不要仅凭整数长度推测；最好设置独立字段或显式格式标记，再调用相应时间戳接口。

能否自动识别 CST 等缩写？本例没有加入时区缩写布局。我更倾向让外部协议提供数字偏移量或另附地点名称，减少双方对缩写的不同理解。

支持多个布局是否就能判断用户真正想表达的时间？不能。它只能按约定解析文本，无法补齐用户没有提供的业务背景。特别是日期、模糊日期顺序等输入，应在接口契约中先作决定。

结果是否保留原始格式？只保留自定义类别标签。若下游依赖原始小数秒位数或原始文本，应另存原文，不要从 Format 字段反推。

官方参考：ParseInLocation、Parse 的布局与小数秒规则、time 解析实现。