每小时数据的时间序列预测我刚刚看过曹剑关于时间序列预测的非常有趣的网络研讨会，所以我想尝试一下一个测试数据集，其中我每隔三个小时记录一次温度，持续了几年。 但是，当我在时间戳中输入日期和时间时，会出现错误消息：不支持的时间格式。 我在“时间”输入选项下尝试了每种单一格式的连续变量。 当然，JMP Pro 16有一种方法可以在几天之内每天进行一次每小时的解释，对吗？
分析工具回复：使用每小时数据进行时间序列预测嗨安德森，
似乎“时间序列预测”平台需要日期或简单的数字时间戳。 我认为它不适用于您的时间列，因为它是一种日期时间格式。
我将您的时间戳转换为数字（格式=最佳），并且时间序列预测现在接受了（附加）。 我认为此数字时间戳记是自1970年1月1日以来的秒数或类似时间。
我不确定为什么“时间序列预测”不接受您的日期时间格式。 将其发送给JMP技术支持（support@jmp.com）可能是个好主意，这样他们就可以进行调查并潜在地记录为缺陷。
希望对您有所帮助，
菲尔
回复：使用每小时数据进行时间序列预测事实证明，JMP日期时间值的始发时间（epoch）是1904年1月1日凌晨12点。我读过的最好的解释来自LabVIEW论坛上的Pat Lavezza。LabVIEW与JMP使用相同的纪元，其起源可以追溯到Apple计算机
“这是1904年1月1日的协议。 大多数（全部？）操作系统将时间存储为自一定时间以来的秒数（或微秒等）。 这次称为时代。 Mac可以存储的秒数大约为130年。 程序员希望该系统能够覆盖大多数用户的生日，因此这个时代需要在20世纪初开始。 那么，为什么不从1900年1月1日开始呢？
Macintosh设计人员需要将大量代码压缩到非常少量的ROM / RAM中。 他们正在寻找可以为他们节省一些空间的任何调整方法。 将纪元以来的秒数转换为日期（例如1973年3月29日）的代码需要知道一年中有多少天。 这意味着您需要代码来确定一年是否为a年。
一年是a年，如果是4的倍数除非是100的倍数除非它也是400的倍数。因此，1900年不是年（100的倍数），但2000年是（100的倍数，但也是400的倍数）。 通过避开1900年，Mac设计师无需担心the年规则的100/400部分（因为130年的跨度仅涵盖2000年的2000年）。 如果年份是4的倍数，则它是a年。
那么为什么不使用1901或1902或1903？ 从a年开始，他们就不需要“补偿”，而这只是节省一点空间的另一种方法。
而且自从LabVIEW在Mac上启动以来，它继承了其中的一些怪癖。”
仅供参考，SAS时代是1960年1月1日
回复：使用每小时数据进行时间序列预测@txnelson谁知道？ 感谢您分享这段历史。 我认为“ Jeopardy”的作家/制作人可以在那种解释的基础上创建一个完整的类别。
回复：使用每小时数据进行时间序列预测这是一个有趣的花絮，谢谢吉姆。 当然，JMP 最初是为 Mac 设计的，因此与 Mac 的连接是有意义的。
