#!/bin/sh
# Show date and time in other time zones
search=$1
zoneinfo=/usr/share/zoneinfo/posix/
format='%a %F %T'
find -L $zoneinfo -type f \
| grep -i "$search" \
| while read z
do
d=$(TZ=$z date +"$format")
printf "%-34s %23s\n" ${z#$zoneinfo} "$d"
done
Kiritimati在UTC+14时与UTC的偏移量最大。Pacific/Pago_Pago是UTC-11时与UTC偏移量最大的地方之一。
如果你去World Time Zone,他们列出了两个无人居住的岛屿,如果有人居住,可能在UTC-12。然而,Olson数据库并没有记录自1970-01-01截止日期以来无人居住的地方的时区信息,所以没有列出这些地方。在
我使用这个,这与其他建议基本相同,只是它过滤了您想要查看的特定区域:
样本输出:
^{pr2}$简单系统
从来没想过,但也不是很难做到。在
给定输入文件:
^{pr2}$我得到了输出:
我很幸运,这只花了不到一秒钟的时间跑完,而且没有跨越1秒的界限。在
(我没注意到加尔各答失败了,默认为GMT。也许我的系统仍然有亚洲/加尔各答作为进入印度的入口。)
修正打字错误
11年后,我在加尔各答错拼了两个t,这里应该只有一个;谢谢你,@{a2}。我还在数据文件中添加了两个额外的条目&},这两个条目分别与UTC有半小时和四分之三小时的偏移量(加尔各答也有半小时的偏移量)。例如,会产生:
America/St_Johns
(纽芬兰)和{请注意,
US/Pacific
是一个古老的时区名称,它不是首选名称;它应该是America/Los_Angeles
。在把这些区域按顺序分类也许是明智的。添加
sort -b -r -k2,2 -k3,3
以按顺序列出时区,其中UTC最前面的时区列在最前面,最远落后的时区列在最后。-b
选项(忽略字段的前导空格)很重要。再加上三个区域(Pacific/Honolulu
,Pacific/Kwajalein
,Pacific/Kiritimati
),得到:请注意,基里蒂马蒂和檀香山的时间是相同的,但日期相隔一天。当然,排序应该在脚本中:
并且
worldclock.zones
文件包含:Kiritimati在UTC+14时与UTC的偏移量最大。
Pacific/Pago_Pago
是UTC-11时与UTC偏移量最大的地方之一。 如果你去World Time Zone,他们列出了两个无人居住的岛屿,如果有人居住,可能在UTC-12。然而,Olson数据库并没有记录自1970-01-01截止日期以来无人居住的地方的时区信息,所以没有列出这些地方。在全球26个时区
为了娱乐(简单的头脑很容易侧移),下面是一个时区名称列表,其中一个名称来自世界各地的大部分时区偏移量。是否有其他使用中的小时差(澳大利亚?),请告诉我。注意标准时间和夏时制时间-一些南半球的条目可能在夏令时。在2020年1月,该清单产生了所有的积分小时偏移量,但在2020年6月可能不会实现。在
该列表包括两个组成的区域名称:},它们分别位于UTC+12和UTC-12。这种积极和消极之间的冲突是因为存在相互冲突的标准。ISO 8601指定UTC以东(格林威治子午线,或多或少)使用UTC的正偏移,UTC以西的地方使用负偏移。同时,POSIX(又名ISO 9045)指定了相反的约定—UTC以西的地方使用正偏移量,而东部的位置使用负偏移量。这两个名称是POSIX时区名称,用于TZ环境变量,并使用偏移量和无夏令时规则进行指定。它们受POSIX偏移规则的约束。为什么会有差异?从根本上说,POSIX遵循了Unix的惯例——它不能在不破坏大量代码的情况下改变它们。ISO8601独立于POSIX,它从第一原则中派生出规则,并提出了一个合理的系统——但POSIX恰恰相反。在
FarEast-12
和{区域名称列表:
修改后脚本的输出示例(排序到位):
时光流逝,现在东京已是午夜过后。在
我有一个bourne shell脚本:
相关问题 更多 >
编程相关推荐