首先直接说结论， timestamp 不带时区信息，timestamptz 带有时区信息。
在 insert 数据的时候，timestamp 不会携带时区信息，timestamptz 会携带 当前会话 使用的时区信息
在查询的时候如果时区没有改变，则查询结果一样。
如果 会话使用的时区 和 数据保存的时区1️⃣（也就是插入数据的时候使用的时区，不手动设置时区的话就是配置文件中的时区）不同的时候， timestamp 查询到的时间不变，timestamptz 查询到的时间，会根据时区差自动改变
从官方手册时间类型部分，能找到这样一句话
SQL要求只写timestamp等效于timestamp without time zone，并且PostgreSQL™鼓励这种行为。timestamptz被接受为timestamp with time zone的一种简写，这是一种PostgreSQL™的扩展。
摘录来自
PostgreSQL 13.1 手册
PostgreSQL 全球开发组
https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewBook?id=0
此材料可能受版权保护。
以下是对上述的一些验证
为了验证时区问题，让结果更容易理解，首先修改了配置文件中的时区配置，配置文件可以通过命令 show config_file 找到
# 将时区修改为 UTC 时区，也就是0时区
log_timezone = 'Etc/UTC'
timezone = 'Etc/UTC'
新建一张测试表
create table test_time (
id serial,
t1 timestamp,
t2 timestamptz
)
插入一条测试数据，并查看当前时区
这个时候插入的数据和查询的数据没有区别，只是
t2 字段后面多了 +00 表示时区
我们切换时区到上海，也就是 +8时区 ，再次查询，需要注意，这里通过会话设置的时区仅对当前会话有效
这个时候我们可以看到 t1 时间没有改变，而t2 时间，随着时区增加了8个小时。
第二次验证
我们在 +8 时区的基础上，再次插入一条数据
然后我们重启开启一个新的回话，这样回话的时区就变回了数据库默认的UTC时区
这个时候，我们会看到，原来的第一条数据，查出来的结果又变成一样的了。
而第二条数据的 t2 字段，时间已经减小了8个小时
1️⃣ 数据保存的时区 这个词语的表述可能有问题，这里仅仅是为了方便理解。
