Go time 怎样用 Date 获得指定时区的日期边界

用 Go 的 time.Date 获得指定时区的日期边界，核心是把选中的年、月、日与同一个 *time.Location 组合：当天零点作为开始，次日零点作为不包含的结束。对两个午夜都存在且唯一的日期，采用 [start, end) 就能表达“这个业务日期内”，不必凑出 23:59:59.999999999。

例如报表用户选择“2026-10-18，Asia/Shanghai”，意思是上海日期，不是服务器恰好运行在哪个时区的日期。下面是原创教学示例，未在本机运行；涉及历史上午夜跳变或重复的时区时，还需要额外规则，不能仅凭通用构造函数保证覆盖所有情况。

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

把日期和业务时区作为两个输入

日期选择器通常只提供 2026-10-18 这样的日历值；它还不是一个完整时间点。界面需要明确它属于哪个业务时区，后端也要接收同样的约定。不要先把这个字符串当 UTC 时间，再试图通过显示转换补救业务含义。

这里把输入拆为 year/month/day 和 loc。time.LoadLocation 用 IANA 时区名加载规则；加载失败应返回可理解的错误，不要悄悄回退到 time.Local。如果任务是从已有时间点取“当地今天”，先做 t.In(loc) 再取 Date()；如果任务是用户选中某天，就直接使用选中的年月日。

用两次 Date 构造当天与次日午夜

先看一个完整实现。函数对输入范围做业务限制，也检查 Date 归一化后的日期，避免把不存在的普通日期当成用户原本输入。函数的适用前提仍是两个边界午夜存在且唯一，下面的回读检查并不是重复午夜检测器。

package main

import (
    "fmt"
    "log"
    "time"
)

// dayBounds 适用于两个边界午夜都存在且唯一的业务日期。
func dayBounds(year int, month time.Month, day int, loc *time.Location) (time.Time, time.Time, error) {
    if loc == nil {
        return time.Time{}, time.Time{}, fmt.Errorf("业务时区不能为空")
    }
    if year  9998 || month  time.December || day  31 {
        return time.Time{}, time.Time{}, fmt.Errorf("日期超出业务输入范围")
    }

    start := time.Date(year, month, day, 0, 0, 0, 0, loc)
    // Date 会归一化越界值，不能仅凭构造成功认定输入日期合法。
    y, m, d := start.Date()
    if y != year || m != month || d != day {
        return time.Time{}, time.Time{}, fmt.Errorf("日期无效或在该时区中被归一化")
    }

    // 日历上的下一天，不是当前时刻加固定24小时。
    end := time.Date(year, month, day+1, 0, 0, 0, 0, loc)
    for _, boundary := range []time.Time{start, end} {
        h, min, sec := boundary.Clock()
        if h != 0 || min != 0 || sec != 0 {
            return time.Time{}, time.Time{}, fmt.Errorf("午夜被时区转换调整，需要业务规则处理")
        }
    }
    if !end.After(start) {
        return time.Time{}, time.Time{}, fmt.Errorf("日期范围没有正长度")
    }
    // 以上检查不能判定所有重复午夜；调用方仍须限定支持的时区和日期。
    return start, end, nil
}

func main() {
    loc, err := time.LoadLocation("Asia/Shanghai")
    if err != nil {
        log.Fatal(err) // 时区加载失败时停止，不偷偷改用服务器Local。
    }
    start, end, err := dayBounds(2026, time.October, 18, loc)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println("开始（包含）:", start.Format(time.RFC3339))
    fmt.Println("结束（不包含）:", end.Format(time.RFC3339))
    // UTC只改变时间的表示，不重新定义选中日期。
    fmt.Println("UTC参数:", start.UTC().Format(time.RFC3339), end.UTC().Format(time.RFC3339))
}

第二次 Date 使用 day+1，是有意利用日历归一化处理月末跨月和年末跨年。第一次 Date 则回读年月日，防止错误输入被静默改成另一天：例如二月里越界的日号不应自动被解释成三月的有效筛选条件。

读者自行运行时，应检查本地开始日期是所选日期、本地结束日期是次日；这只是预期语义，没有附会成本文的实际输出。开始和结束对应的 UTC 表示可能落在不同于页面日期的 UTC 日历日期，这本身不表示计算出错。

将边界用于左闭右开的筛选

日期范围的判断要写成“时间不早于 start，同时早于 end”。这样，相邻两天共享同一个边界点，却不会把这个点算进两天。它也不依赖数据源究竟保存到秒、毫秒还是纳秒。

// start和end来自同一业务时区下的日期边界；不把结束点归入当天。
func inDay(t, start, end time.Time) bool {
    return !t.Before(start) && t.Before(end)
}

上面的 inDay 接收完整时间点 t 以及同一范围的 start、end。Before 比较时间点，不能用格式化后的本地日期字符串排序来代替。若数据接口使用 UTC，先在业务时区定义边界，再把这两个边界转换为 UTC 参数；不要反过来用 UTC 的零点重新切分业务日。

让页面显示与后端边界使用同一口径

在筛选区给日期输入配上明确的文字标签，并同时展示业务时区。不要只用颜色表达“结束不包含”；可以在帮助文字中写“查询所选业务日期，至次日零点前”。无效日期或不支持时区的错误应关联到相应输入，键盘和辅助技术用户也能知道该改哪个条件。

请求完成后，结果摘要仍显示用户选中的日期和时区，而不是只展示转换后的 UTC 日期。这是界面与后端契约的一部分，并不要求额外绘制软件界面。服务端可在配置阶段加载受支持的时区，复用 Location；真正影响查询性能的因素另需在项目中测量，不能从这段时间构造代码推导性能收益。

识别夏令时与不存在的日期

夏令时意味着日历日没有固定时长；因此，在适用前提成立时构造两端当地午夜，比“开始加 24 小时”更贴近按日查询的含义。AddDate 也是日历运算，但它和 Date 一样存在归一化与特殊本地时间的边界，不能用来自动消除所有历史歧义。

官方 Date 文档明确：本地时间在跳变时可能不存在或重复，涉及哪个时区偏移并不总有唯一答案。本文的函数会拒绝一部分可见的归一化结果，但没有声称能够识别所有重复午夜、跳过日期或特殊政治时区调整。支持全球历史日期的系统，应先制定“取最早有效时刻、拒绝歧义还是按业务表处理”等政策，再实现专门逻辑。

日期范围能用当天最后一纳秒吗？

可以构造这样的时间，但对筛选接口更建议用不包含的次日边界，避免依赖存储精度以及末尾舍入方式。

服务器在 UTC 部署会改变边界吗？

显式使用已加载的业务 Location 时，不应让服务器 Local 决定日期含义；仍要保证部署环境具备所需时区数据并处理加载错误。

为什么不能直接取 time.Now 的年月日？

那取到的是该值当前 Location 下的日期。按指定时区计算今天，应先转换 Location；查询用户指定日期时，不应该用当前日期替代输入。

参考文档：https://pkg.go.dev/time#Date、https://pkg.go.dev/time#Time.AddDate、https://pkg.go.dev/time#Time.Truncate、https://pkg.go.dev/time#LoadLocation。