不同时区的日期导入

mseeds

我和我的团队在不同的时区。我在服务器上创建了一个数据集，其中第一行为2019年3月1日。因为我没有提供时间，所以它把我的时间设置为午夜。我的时区在德克萨斯州，CST。如果我把这个值复制粘贴到记事本上，它会变成:

2019年3月1日星期五00:00:00

我的队友坐在加州，日期显示为Feb 28, 2019。他的时区比我的晚两个小时。当他复制粘贴时，上面写着

2019年2月28日星期四22:00:00太平洋标准时间

我们在连接中遇到了其他日期时间问题，因为这是基于谁将文件导入到他们的系统，追加或连接，然后共享结果。我们有一些数据集，其中一个人的日期显示为差一天，或者由于2小时的时差而无法加入日期。

当您知道要跨时区工作时，导入日期的最佳实践是什么?我们目前正在探索一种变通方法，将日期作为名义值导入，然后使用社区构建块将它们转换为RapidMiner日期，但这感觉像是一个笨拙的解决方案。

谢谢,
玛吉
@sgenzer

rfuentealba

你好,@mseeds！

是的，我有一些想法，但不是很好。如果你愿意，我们可以反复地找出最适合你的解决方案。

使用日期是相当痛苦的(这不是RapidMiner的错，虽然…我在PostgreSQL中也看到过非常奇怪的事情)，我通常最终生成一个名为“Nominal Date”左右的新属性，其结构如下:

concat(
 str(date_get(Date, DATE_UNIT_YEAR))，
 "-"，
 if (
 date_get(Date, DATE_UNIT_MONTH) + 1 
 if (
 date_get(Date, DATE_UNIT_MONTH) + 1)，
 str("0"， str(date_get(Date, DATE_UNIT_MONTH) + 1)
)，
 "-"，
 if (
 date_get(Date, DATE_UNIT_DAY))< 10，
 concat("0"， str(date_get(Date, DATE_UNIT_DAY)))，
 str(date_get(Date, DATE_UNIT_DAY))
)
 str(date_get(Date, DATE_UNIT_DAY))
)

我附上了展示这一点的过程，如果有人想从中制作一个构建块，我很乐意分享我在日期处理方面的其他23个技巧，因为RapidMiner不处理日期(在日期的意义上)。

现在，让我写下我的沮丧，因为我一小时前也在与类似的事情作斗争。我先道歉。

之前IEEE 754标准(和其他标准)，可以用所谓的数据图 ，因此定义日期可以定义为9999-12-31，这可以挽救任何一种西方约会。顺便说一下，19年前发生的千年虫问题的部分原因是COBOL开发人员可以将日期定义为99-12-31以便在他们的计算机上节省宝贵的字节。好吧，尽管有一些数据类型的标准，但对于日期却没有这样的标准(除了ICU项目，但这更多的是一个需要克服的实现大量的怪癖(与处理日期一起存在)。考虑到这一点，语言实现设计者定义了两种日期:一种称为EPOCH整数(从1970年1月1日UTC开始计数)，另一种是时间戳结构。

现在，RapidMiner处理EPOCH和完整的时间戳结构，但是在它的实现中，似乎没有日期时间、日期、时间、带时区的日期时间、带时区的时间或内部时间戳之间的区别。所有这些都以带时区的时间戳的形式存储(计算起来更简单，但跨多个时区工作就像用小脚手指撞到墙角一样痛苦)，但在需要时使用数据图 我们上面描述的概念。

您建议使用日期作为名义值是一种可能的情况，但这完全取决于您的用例:也许使用呼叫中心网络需要使用时区注册呼叫的时间戳，而某些流程仅在一年中的几个月、几个季度或更多的情况下有效。

@mseeds如果这里的解决方案适合你，请告诉我。如果没有，我们可以重复一些事情，找出如何帮助你。

愿一切都好！

杆。

Marco_Boeck

你好,

可爱的话题!与日期打交道总是很有趣，尤其是像夏令时、切换秒、有时跳过整整一天的奇怪地方(为什么不呢?)等等。围绕这个话题有很多奇怪和例外，这是荒谬的。如果我们只有UTC，地球上所有地方的时间都是完全相同的，没有不规则和例外，世界将会变得更好，数百万小时或生产力将会被节省下来。

不管怎样，我离题了。所以事情是这样的:在内部，所有的日期时间都是从epoch开始以毫秒为单位存储的(参见https://currentmillis.com/)。因此，如果您有一个datetime列，那么实际的数据对于您和您的同事来说将是相同的，而不管您使用的是哪个本地时区。但是，因为人们喜欢自己熟悉的时区，所以我们以您当地的时区(或者您在Studio的首选项中选择的时区)显示日期。然而，这只是显示，数据中的实际值仍然是从epoch开始的毫秒。

加入它不是问题，因为从epoch开始的毫秒数是相同的。
然而，如果您正在进行一些转换到新的日期对象或字符串，并且如果在时区(UTC)由于配置错误或错误而无声地丢失的方式中，您可能会开始遇到问题，那么例如系统时区可能会被假定，并且一切都将陷入困境。

此外，如果您同时从“now()”创建一个日期，那么无论您在世界的哪个地方，它在数据中的值都是完全相同的-有一个值得注意的问题:它使用系统时钟来完成此操作。如果系统时钟不同步，前面的语句不再成立。

问候,
马可

rfuentealba

嗨,麦琪,

我永远不会转换原始数据，因为很难看到数据是在哪里生成的。相反，我会为我的特定问题生成新的属性。在使用nominal to date操作符方便时，将日期生成为标称日期并进行解析，保留原始属性似乎是正确的做法，即使它看起来像一个绷带。

让我看看能不能给你发几个例子。我现在正在开会。

愿一切都好！

罗德里戈。

kayman

Marco的建议与我们采用的方法相同(多区域数据与当地时间风味)。所以日期到数字给了我们一个统一的格式，如果我们以后需要做日期操作，它只是一个数字到日期的问题。

比使用名义转换要安全得多。

varunm1

你好@mseeds

你可以在设置->首选项->常规中检查时区。我认为最好遵循像GMT或UTC这样的标准时间，这样系统时间就不会影响您的进程(或者)不同时区的人可以将他们的工作室时区设置为类似于服务器时区。但是，如果您在服务器上更改了某些内容，那么在所有地方(Studio)都要更改。

下面是详细的解释:
https://community.www.turtlecreekpls.com/discussion/36312/change-system-time

@rfuentealba你的见解在这里很有帮助。

希望这对你有所帮助。

mseeds

嗨，罗德!
感谢所有的背景信息!对于我的用例，我只需要日期值，因为我要将行聚合到日期级别。澄清一下，您的建议是将所有日期转换为标称日期而不使用日期类型吗?这似乎是一个创可贴，因为我想能够使用日期函数(例如提取一周的一天)。

rfuentealba