因为时区缩写并未被很好地标准化,LightDB提供了一种方法来自定义服务器所接受的缩写集合。timezone_abbreviations运行时参数决定活动的缩写集合。虽然这个参数可以被任何数据库用户修改,但它的可能值是受到数据库管理员的控制的 — 它们实际上是存储在安装目录的.../share/timezonesets/
子目录中的一些配置文件。通过在那个目录中增加或修改文件,管理员可以为时区缩写设定本地策略。
timezone_abbreviations
可以被设置为任何在.../share/timezonesets/
中可以找到的文件名,前提该文件的名字完全是字母的(timezone_abbreviations
中禁止非字母字符防止从预期目录的外面读取文件以及读取编辑器的备份文件和其他外部文件)。
一个时区缩写文件可以包含空行和以#
开始的注释。非注释行必须具有下列格式之一:
zone_abbreviation
offset
zone_abbreviation
offset
Dzone_abbreviation
time_zone_name
@INCLUDEfile_name
@OVERRIDE
一个zone_abbreviation
就是被定义的缩写。offset
是一个整数,它给出以秒计的到 UTC 的等效偏移量,为正表示东起格林威治,为负表示西起格林威治。例如, -18000 表示格林威治西边的五个小时,或者北美东海岸标准时间。D
指示该区域名表示本地夏令时而非标准时间。另外,还可以给出一个time_zone_name
,在这种情况下会查阅该时区定义,并且会使用该时区中的缩写含义。这种替代方案只用于那些含义在历史上有变化的缩写,因为比起使用一个固定的整数值,查找该含义开销要大得多。
另外,还可以给出一个time_zone_name
,它引用 IANA 时区数据库中定义的时区名。这时会参考该时区的定义来判断在时区中是否有或者使用了该缩写。如果是,会使用适当的含义 — 也就是正在判断其值的时间戳中当前使用的含义,或者之前刚刚使用的含义(如果当时不是当前),或者最老的含义(如果只在那时之后用过)。这种行为对于处理其含义在历史上变化过的缩写是至关重要的。也允许按照缩写没有出现在其中的时区名来定义缩写,这样使用该缩写就等效于直接写出该时区名。
在定义其 UTC 偏移没有改变过的缩写时,使用简单的整数offset
更好,这样的缩写在处理时代价比那些需要查阅时区定义的缩写更低。
@INCLUDE
语法允许包括.../share/timezonesets/
目录中
的其它文件。允许进行嵌套包括,但是嵌套深度有限制。
@OVERRIDE
语法表示文件中后续项可以覆盖前面的项(典型的:从被包括的文件中
得到的项)。如果没有它,同一个时区缩写的相互冲突的定义会被认为是一种错误。
在一个未被修改的安装中,文件Default
包含用于世界大部分地区的非冲突时区缩
写。附加文件Australia
和India
被提供给那些地区:这些文件
首先会包括Default
文件,并且接着根据需要增加或修改缩写。
为了便于参考,标准安装也包含了Africa.txt
、America.txt
等文件,它们包含了所有根据IANA 时区数据库中已知正在使用的时区缩写信息。 如果需要,这些文件中的时区名定义可以复制并粘贴到自定义的配置文件中。注意这些文件名
不能直接被timezone_abbreviations
设置引用,因为它们的名称中嵌有句点。
如果在读取时区缩写集时发生错误,将不会应用任何新值并且保留旧的集合。如果该错误是在数据库 启动时发生,那么启动将失败。
配置文件中定义的时区缩写将会覆盖LightDB中内建的非
时区含义。例如Australia
配置文件定义了SAT
(南澳洲标准时
间)。当该文件为活动时,SAT
将不会被识别为周六的缩写。
如果你修改.../share/timezonesets/
中的文件, 那么你必须自己创建备份 — 因为通常的数据库转储不会包括这个目录。