ERDDAP > 转变 > 时间

将字符串时间转换为数字时间

在ERDDAP的各个地方，时间点可以表示为：

字符串- ERDDAP始终使用ISO 8601:2004 "extended"格式 yyyy-MM-ddTHH:mm:ssZ - 例如， ERDDAP :00:00Z 。ERDDAP 之外的数据集通常对字符串时间值使用不同的格式。
数字- 当将时间表示为数字时， ERDDAP始终写入与UDUNITS兼容的数字 - 例如， n=473472000 单位= "seconds since 1970-01-01T00:00:00Z" 。ERDDAP对所有数据集都使用精确的单位字符串ERDDAP之外的数据集通常使用ERDDAP的单位字符串。

此网页具有转换器，可以将字符串时间值（具有各种格式）转换为数字时间值（具有各种单位字符串）。它还具有转换器，可以将使用其他格式的时间字符串和单位字符串转换为ERDDAP使用的格式。

为了避免时区和夏令时混淆， ERDDAP中的时间值始终使用Zulu (UTC、GMT) 时区，用“Z”表示。以下转换器接受其他时区的字符串时间。

将表单重置为默认值。

或者，绕过此网页并从计算机程序、脚本或网页内部进行转换。

关于时间转换器的说明

责任免责声明——与本网站相关的任何个人或组织均不做任何明示或暗示的保证，包括适销性和针对特定目的的适用性的保证，也不对本网站上任何信息的准确性、完整性或实用性承担任何法律责任。
不完美- 这些转换器不完美。请务必检查这些转换器的结果。
这些转换器接受大量字符串时间格式，但总会有一些格式无法识别或解释方式与您不同。在某些情况下，有两种或更多种常见但不同的方法来解释给定的时间格式，特别是 #/#/#：在美国，通常应为月/日/年，而在欧洲大部分地区，通常应为日/月/年。在这种特殊情况下， ERDDAP将值解释为月/日/年。
UDUNITS时间单位- 例如， "seconds since 1970-01-01T00:00:00Z" 。第一个单词可以是（大写或小写）：
  ms, msec, msecs, millis, millisecond, milliseconds,
  s, sec, secs, second, seconds,
  m, min, mins, minute, minutes,
  h, hr, hrs, hour, hours,
  d, day, days,
  week, weeks,
  mon, mons, month, months,
  yr, yrs, year, or years 。
"since"是必需的。
另一个例子是"hours since 0001-01-01" 。
时间字符串可以采用任何格式。日期部分是必需的。时间部分是可选的ERDDAP将尽力读取您提供的格式。建议的格式是 ISO 8601:2004 "extended"格式yyyy-MM-dd THH:mm:ss.SSSZ，其中 Z 是“Z”或与Zulu Zulu GMT 时区。另外，如果省略 .SSS、:ss.SSS、:mm:ss.SSS 或 Thh:mm:ss.SSS，则缺失的字段将假定为 0。
从技术上讲， ERDDAP在将"years since"和"months since" UDUNITS值转换为"seconds since"时不遵循UDUNITS标准。UDUNITS 标准将年份定义为一个固定的单一值：3.15569259747e7 秒。而UDUNITS将月份定义为年/12。不幸的是，我们看到的大多数/所有使用"years since"或"months since"的数据集都明确表示这些值是日历年或日历月。例如，3 "months since 1970-01-01"通常表示 1970-04-01。因此， ERDDAP将"years since"和"months since"解释为日历年和月，并不严格遵循UDUNITS标准。
转换器精度- 当将时间表示为数字时，此转换器始终保留数字的完整精度。当将时间表示为字符串时，此转换器将时间格式化为（截断的）秒（即省略毫秒）。
无效输入- ERDDAP尝试处理格式不正确的输入。如果ERDDAP无法处理输入， ERDDAP将生成错误消息。如果您认为“无效输入”是字符串时间，并且应该得到支持，请将其通过电子邮件发送至erd dot data at noaa dot gov 。

ERDDAP如何处理时间

时间是一个困难、复杂、混乱的问题。
目标- ERDDAP系统处理时间的一个基本目标是拥有一个单一系统，允许将任何数据集的时间数据与任何其他数据集的时间数据直接进行比较。阅读下面的其他评论时请记住这一点。
时间点- ERDDAP仅处理时间点（ Zulu时区中的日期+时间的组合，每个都是时间中的一个瞬间）。
时区- 写入时间值时， ERDDAP始终使用Zulu (UTC、GMT) 时区，从不使用夏令时。来自具有时区信息（可能包含夏令时信息）的源的时间数据将转换为Zulu时间。来自没有时区信息的源的时间数据被认为已经是Zulu时间。
精度- ERDDAP在内部将时间处理为"seconds since 1970-01-01T00:00:00Z" ，忽略闰秒，存储为双精度浮点数。因此，大多数时间数据可以非常精确地存储（大致精确到微秒，但过去或将来的精度逐渐降低）。
在进行计算时， ERDDAP通常精确到毫秒，以避免出现比预期略多或略少的浮点数问题。
当用数字表示时间时， ERDDAP始终保留数字的完整精度。
默认情况下，当将时间表示为字符串时， ERDDAP会将时间格式化为（截断的）秒（即省略毫秒）。但是， ERDDAP管理员可以配置特定数据集中的特定变量，以其他精度表示字符串时间（例如，从毫秒精度到月精度；请参阅<time_precision>变量属性）。当未显示时间字段（例如毫秒或秒）时，缺失的值假定为 0（除日期外，假定为 1）。
一致的单位- 对所有数据集使用相同的时间单位（ "seconds since 1970-01-01T00:00:00Z" ），可以轻松比较不同数据集的时间。秒是国际单位制 (SI) 时间的基本单位。1970-01-01T00:00:00Z 是 Unix 纪元的开始，被计算机操作系统广泛使用。 "seconds since 1970-01-01T00:00:00Z"被广泛使用，通常称为Unix 时间或纪元秒。使用单位字符串"seconds since 1970-01-01T00:00:00Z"使 Unix 时间与UDUNITS兼容以及气候和预报元数据公约（CF），使用UDUNITS进行单位定义。
文本表示- 默认情况下，当将时间格式化为文本时， ERDDAP使用ISO 8601:2004 "extended"格式字符串，截断到秒（例如，2011-04-26T14:07:12Z）。（相关幽默： https://xkcd.com/1179/ ) ERDDAP管理员可以配置给定变量以更高精度（截断到 0.001 秒、0.01 秒、0.1 秒）或更低精度（截断到秒、分钟、小时、日期或月份）显示时间数据值，以指示时间数据值的精度。
读取带有十进制秒的 ISO 8601 时间时， ERDDAP接受句点分隔符（例如，2011-04-26T14:07:12.059Z）或逗号分隔符（例如，2011-04-26T14:07:12,059Z）。目前，在写入 ISO 8601 时间时ERDDAP始终使用句点分隔符。
公历- ERDDAP使用公历来表示 1582 年中断之后的时间，使用儒略历来表示中断之前的时间。（ISO 8601:2004 标准未指定如何处理 1582 年之前的时间。）请参阅Java GregorianCalendar 类（ ERDDAP使用）了解详情。例如，自 0001-01-01T00:00:00Z 以来的 17611992 小时 = 2010-03-01T00:00:00Z（自己查看）
目前， ERDDAP不支持任何其他日历（包括CF 元数据约定定义的 noleap、365_day、360_day 和儒略历)。但是，您可以将此类数据存储在ERDDAP中，方法是将数字或字符串存储在名为"time"以外的变量中，并且单位元数据中不包含"since" 。这样， ERDDAP就不会将这些值解释为时间，也不会将数据转换为"seconds since 1970-01-01T00:00:00Z" 。用户将能够以原始形式访问数据。
宽松- ERDDAP在解析日期/时间字符串时是“宽松的”。这意味着，如果日期/时间格式正确，但月份、日期、小时、分钟和/或秒值过大或过小，则将滚动到适当的日期/时间。例如， ERDDAP将 2001-12-32 解释为 2002-01-01，将 2002-01-00 解释为 2001-12-31。（这不是错误，而是一项功能！如果您不熟悉宽松解析，我们知道您可能会反对这一点。我们知道在某些情况下有些人更喜欢严格解析，但也有一些情况下有些人更喜欢宽松解析。ERDDAP 不能两全其美。这是一个有意识的选择。宽松解析是Java中的默认行为， ERDDAP是使用ERDDAP编写的语言，可以说是使用最多的计算机语言。此外，此行为与ERDDAP将请求的网格轴值转换为最接近的有效网格轴值一致。并且这与ERDDAP中的其他一些地方一致，当意图明确时，这些地方会尝试修复无效输入，而不仅仅是返回错误消息。）
公元前 (BC)年和天文年编号 - 根据 ISO 8601:2004 标准的规定， ERDDAP仅使用公元 (CE、AD) 作为年份编号，而不是公元前。对于公元 1 年之前的年份，历史学家使用公元前或公元前的名称，而不使用 0 年，因此他们接近时代过渡的年份顺序是公元前 2 年、公元前 1 年、公元 1 年、公元 2 年。对于公元前 1 年之前的年份，ISO 8601:2004 标准（根据我的理解）鼓励使用不同的系统：天文年编号，其中公元前 1 年称为 0000 年，公元前 2 年称为 -0001 年，等等。由于 ISO 8601:2004 鼓励使用天文年份编号，并且许多科学领域都使用天文年份编号，而且海洋学家和气候学家经常使用 0000 年作为气候学年份，因此ERDDAP使用天文年份编号。因此， ERDDAP中接近时代过渡的年份分别为 -0001、0000、0001、0002。因此，对于公元前年份：AstronomicalYear = 1 - BCEYear（自己查看： test1 、 test2和test3 ）。天文年份编号的一个优点是所有闰年都可以被 4 整除，例如，...，-0008，-0004，0000，0004，0008，...。如果您记得使用天文年份数字， ERDDAP将适用于过去和未来的日期。
海洋数据网项目将时间存储为“自 -4713-01-01T00:00:00Z 以来的天数”，这是对公元前 4713 年 1 月 1 日午夜的引用，这是Chronological Julian Dates (CJD)的开始时间。因此，在ERDDAP中 SeaDataNet 数据集的datasets.xml设置中，在所有时间变量的<addAttributes>部分中，您需要添加
<att name="units">days since -4712-01-01T00:00:00Z</att>
因此公元前 4713 年表示为天文年数 -4712。为了进行检查，请注意儒略历日数 2,452,952（或2452952 "days since -4712-01-01" ）的开始是 2003-11-08T00:00:00Z。
UTC - ERDDAP与 Unix 时间和UDUNITS一样，尽可能使用协调世界时 (UTC) 时间系统。UTC 是 GMT 时间系统的现代版本。UTC 偶尔会使用闰秒，以接近国际原子时 (TAI)。GPS 设备内部使用 GPS 时间（不使用闰秒），但向用户显示 UTC 时间。（请参阅https://www.cnmoc.usff.navy.mil/Our-Commands/United-States-Naval-Observatory/Precise-Time-Department/The-USNO-Master-Clock/Definitions-of-Systems-of-Time/ 或其他时间系统的讨论。）严格来说，UTC 不能在某些情况下用于遥远的未来时间（例如，在模型中），因为闰秒的发生是无法预测的。
闰秒- 与 Unix 时间和UDUNITS一样， ERDDAP的"seconds since 1970-01-01T00:00:00Z"是 UTC 时间（使用闰秒）的数字编码（不使用闰秒）。在将字符串时间转换为数字时间/从数字时间转换为字符串时间时， ERDDAP与 Unix 时间和UDUNITS一样，会忽略闰秒。但是， ERDDAP 、Unix 时间和UDUNITS数字时间都表示它们使用 UTC。原因和方式如下：由于计算机时钟不是好的计时员，它们会偏离 UTC 时间，有时必须重置为 UTC 时间。Unix 时间将闰秒视为时钟漂移导致的时间偏差的一部分。这允许软件进行时间编码和时间计算并忽略闰秒。使用ERDDAP 、Unix 时间和UDUNITS数字时间值，所有分钟都被视为有 60 秒，即使带有闰秒的 UTC 分钟有 61 秒。请注意，像Oracle这样的数据库程序， MySQL （MariaDB 可能也是如此）、 PostgreSQL 以及C#等语言也基本上尝试忽略闰秒。如果将时间重新转换回 date+time+ Zulu字符串，并且同时忽略闰秒，则将 UTC 字符串 date+time+timeZone 值转换为ERDDAP数值时不会导致问题。这两个错误将相互抵消。一个不幸的后果是ERDDAP 、Unix 时间和UDUNITS数字时间没有机制将实际闰秒明确地编码为数字。例如，闰秒2008-12-31T23:59:60Z和下一秒2009-01-01T00:00:00Z都被编码为1230768000 seconds since 1970-01-01T00:00:00Z 。这是一个缺陷，但只影响实际的闰秒。同样，如果您需要计算两个时间点之间的准确 UTC 秒数，则可以使用ERDDAP来处理时间数据，但从另一个数字时间值中减去一个数字时间值只是计算的第一步。您需要通过查阅闰秒表来手动调整该值。
低分辨率时间和时间跨度（时间范围） - 如果时间数据以较低的分辨率记录（例如，分钟、小时、天、月或年）或表示时间跨度（例如，特定小时、天、7 天周期、月、年），则ERDDAP要求使用时间点（我们称之为“名义时间”）来表示该时间或时间跨度。使用名义时间允许时间点、低分辨率时间点和时间跨度互操作。（想象一下在Google Earth等程序中可视化不同的数据集，并使用时间滑块来控制哪些数据子集可见。）名义时间最常选择的时间点是开始时间和中心时间（不太常见，但使用时间滑块有优势）。我们建议您使用long_name元数据来识别它（例如，“开始时间”或“中心时间”）。对于低分辨率时间，请考虑“日期”、“月份”和“年份”。和/或，将详细信息放在变量的"comment"元数据中。
或者，为了更准确地表示时间跨度，您可以设置一个数据集，使其同时具有beginTime和endTime变量（如果您想涵盖所有可能性，甚至可以centeredTime ）。
这些答案并不完美。当前的设置试图从时间格式混乱中理出头绪，合理地处理大多数情况，并满足大多数人对时间运作方式的期望（即使他们没有详细考虑过），但并非全部。但这就是ERDDAP目前的工作方式。

想要在计算机程序、脚本或网页内进行时间转换吗？

如果将此网页 URL 的扩展名从 .html 更改为 .txt， ERDDAP将仅响应文本结果。

将字符串时间转换为数字时间的示例是：
https://coastwatch.pfeg.noaa.gov/erddap/zh-CN/convert/time.txt?stringTime=1985-01-02T00:00:00Z&units=seconds%20since%201970-01-01T00:00:00Z
或者，您可以使用其他格式，例如，
https://coastwatch.pfeg.noaa.gov/erddap/zh-CN/convert/time.txt?stringTime=Jan%202,%201985&units=seconds%20since%20Jan%201,%201970
将数字时间转换为字符串时间的示例是：
https://coastwatch.pfeg.noaa.gov/erddap/zh-CN/convert/time.txt?n=473472000&units=seconds%20since%201970-01-01T00:00:00Z
单位中基准时间的推荐格式为 ISO 8601 格式，但您可以采用任何常见格式指定基准时间，例如，
https://coastwatch.pfeg.noaa.gov/erddap/zh-CN/convert/time.txt?n=473472000&units=seconds%20since%201/1/1970
请注意，“斜线”格式按照美国方式（月/日/年）解释，而不是按照欧洲方式（日期/月/年）解释。
在ERDDAP的一些早期版本中，字符串到数字转换器需要 ISO 8601 格式的字符串并使用参数名称 isoTime。您仍然可以使用它，例如，
https://coastwatch.pfeg.noaa.gov/erddap/zh-CN/convert/time.txt?isoTime=1985-01-02T00:00:00Z&units=seconds%20since%201970-01-01T00:00:00Z
如果指定 isoTime， "&units=..."参数是可选的。默认值为"seconds since 1970-01-01T00:00:00Z" 。
将任何常见字符串时间转换为 ISO 8601 字符串时间的示例是：
https://coastwatch.pfeg.noaa.gov/erddap/zh-CN/convert/time.txt?stringTime=1/2/1985
您必须指定日期部分。时间部分是可选的。如果您只指定日期，转换器将返回一个日期值。如果您指定日期部分和时间部分，转换器将返回一个日期和一个时间。
请注意，“斜线”格式按照美国方式（月/日/年）解释，而不是按照欧洲方式（日期/月/年）解释。
将单位字符串转换为具有 ISO 字符串时间的单位字符串的示例是：
https://coastwatch.pfeg.noaa.gov/erddap/zh-CN/convert/time.txt?单位=SEC%20SINCE%20Jan%202%2C%201985

百分比编码 - URL 中的参数值（ '='符号后面的部分）必须进行正确的百分比编码 (external link) ：除 A-Za-z0-9_-!.~'()* 之外的所有字符都必须编码为 %HH，其中 HH 是字符的 2 位十六进制值，例如空格变为 %20。#127 以上的字符必须转换为 UTF-8 字节，然后每个 UTF-8 字节都必须进行百分号编码（请程序员帮忙）。有些网站可以为您进行百分号编码和解码 (external link) 。