Mule 在Dataweave中将java.sql.timestamp转换为DateTime

我正在从数据库请求中获取java.sql.Timestamp。该值表示时间上的某个瞬间，因此时区不相关（因此java.sql.Timestamp没有时区，因为它表示全局瞬间）。 我希望使用dataweave将其转换为ISO8601日期时间字符串，但是dataweave正在将我的本地时区（+10:00）添加到该值中

见示例：

%dw 2.0
output application/json
import java!java::sql::Timestamp
---

{
   epoch: 0 as DateTime,
   epochFromDatabase: Timestamp::new(0) as DateTime
}

其中结果/预览为：

{
  "epoch": "1970-01-01T00:00:00Z",
  "epochFromDatabase": "1970-01-01T10:00:00Z"
}

您可以看到，第二个值（epochFromDatabase）在UTC（Z）中增加了+10小时

这只能在dataweave中更正吗？我知道我可以用java纠正这个问题，但我必须只使用dataweave/mule特性

-编辑-- 根据示例，这不是java问题：

Timestamp epochTimestamp = new Timestamp(0);
System.out.println(epochTimestamp.toString());
System.out.println(epochTimestamp.toInstant().toString());
System.out.println(epochTimestamp.getTime());

写道：

1970-01-01 10:00:00.0
1970-01-01T00:00:00Z
0

---

这样，toString确实意味着一个本地时间轴（而不是iso8601），但当转换为一个瞬间（谁的toString默认为iso8601）时，它是正确的

日期时间总是有一个时区。您可以尝试没有LocalDateTime的LocalDateTime：

epochFromDatabase: Timestamp::new(0) as LocalDateTime

输出：

"epochFromDatabase": "1969-12-31T21:00:00"

---

日期时间总是有一个时区。您可以尝试没有LocalDateTime的LocalDateTime：

epochFromDatabase: Timestamp::new(0) as LocalDateTime

输出：

"epochFromDatabase": "1969-12-31T21:00:00"

---

我只是在这里添加我的想法，以便您可以根据上述意见制定解决方案

DataWeave中日期时间的默认格式实际上是ISO 8601。 因此，我们不需要指定格式字符串，也不需要分别格式化两个成员

我在这里什么也看不见

如果您看到日期不匹配之类的情况，那么您可以尝试如下定义时区

%dw 2.0
output application/json
var utc = "UTC" as TimeZone
fun getFormattedDateTimeZoneBased()=(now() >> utc) as String
---
{
  myDate: getFormattedDateTimeZoneBased()
}

---

我只是在这里添加我的想法，以便您可以根据上述意见制定解决方案

DataWeave中日期时间的默认格式实际上是ISO 8601。 因此，我们不需要指定格式字符串，也不需要分别格式化两个成员

我在这里什么也看不见

如果您看到日期不匹配之类的情况，那么您可以尝试如下定义时区

%dw 2.0
output application/json
var utc = "UTC" as TimeZone
fun getFormattedDateTimeZoneBased()=(now() >> utc) as String
---
{
  myDate: getFormattedDateTimeZoneBased()
}

---

我不知道你为什么会有这种差异，我明白了。但是你试过暴力的方式吗？i、 e.

Timestamp:：new（0）-| PT10H |

对于记录，java也给出了相同的差异——我编写了一个类并尝试了它。我已经很久没有使用Java了，但我很确定它与Java有关，而不是与DW有关。谢谢George，我不想假设服务器所在的时区。更不用说夏令时意味着它将改变它的位置。我编辑了这个问题以证明它不是java问题，getTime（）方法返回的值与构造它时使用的值相同。当我在我的系统中运行您的代码时，我得到以下

1969-12-31 16:00:00.0 1970-01-01T00:00:00Z 0

。

getInstant

方法是唯一一个给出日期时间而不调整TZ的方法。不确定为什么会出现这种差异，我将其添加到。但是你试过暴力的方式吗？i、 e.

Timestamp:：new（0）-| PT10H |

对于记录，java也给出了相同的差异——我编写了一个类并尝试了它。我已经很久没有使用Java了，但我很确定它与Java有关，而不是与DW有关。谢谢George，我不想假设服务器所在的时区。更不用说夏令时意味着它将改变它的位置。我编辑了这个问题以证明它不是java问题，getTime（）方法返回的值与构造它时使用的值相同。当我在我的系统中运行您的代码时，我得到以下

1969-12-31 16:00:00.0 1970-01-01T00:00:00Z 0

。

getInstant

方法是唯一一个给出日期时间而不调整TZ的方法。假设我不知道也不想知道服务器所在的时区。我可以编辑这个问题，说我想使用dataweave将时间戳转换为自epoch以来的毫秒，同样的问题也会出现。unix时间戳，或者任何基于毫秒的时间戳都将始终提供时区。并且必须包含要转换为历元的时区信息timestamp@maddestroyer7，在本例中，java.sql.Timestamp是用以毫秒为单位的历元的长表示形式构造的，因此隐含的时区是UTC。然后我将如何使用dataweave将其返回到iso8601或unix时间？假设我不知道也不想知道服务器所在的时区。我可以编辑这个问题，说我想使用dataweave将时间戳转换为自epoch以来的毫秒，同样的问题也会出现。unix时间戳，或者任何基于毫秒的时间戳都将始终提供时区。并且必须包含要转换为历元的时区信息timestamp@maddestroyer7，在本例中，java.sql.Timestamp是用以毫秒为单位的历元的长表示形式构造的，因此隐含的时区是UTC。然后我将如何使用dataweave将其返回到iso8601或unix时间？