2

I have a plain date / time string (local european summer / winter time) I would like to transform into UTC.

The date I receive looks like this

{"message": "2021-05-01 15:39"}

But using LocalDateTime like this

(payload.message as LocalDateTime  {format: "yyyy-MM-dd HH:mm"}  >> "UTC")

will deliver "2021-05-01T15:49:00Z" - while correctly (respectively what I want) it should be "2021-05-01T13:49:00Z".

maco
  • 55
  • 7

2 Answers2

5

One solution is to add the timezone manually:

%dw 2.0
output application/json
var value={"message": "2021-05-01 15:39"}
---
(value.message ++ " CET") as DateTime  {format: "yyyy-MM-dd HH:mm zz"}  >> "UTC"

Output:

"2021-05-01T13:39:00Z"
aled
  • 21,330
  • 3
  • 27
  • 34
3

You can't parse it directly to a DateTime (a date with time and timezone) because you don't have a TimeZone.. so, manually add the timezone and then parse it, which then allows you to convert the timezone to UTC.

(("$(payload.message) +02:00") as DateTime { format: "yyyy-MM-dd HH:mm ZZZZZ" }) >> "UTC"

Which outputs:

"2021-05-01T13:39:00Z"

Edit:

If we are assuming the timezone of the mule application matches the timezone of the date time coming through, and we want to dynamically tack that on, we could do this:

%dw 2.0
output application/json
fun currentUTCOffset() = now() as String { format: "ZZZ" }
---
(("$(payload.message) $(currentUTCOffset())") as DateTime { format: "yyyy-MM-dd HH:mm ZZZ" }) >> "UTC"

This is why it is so important for people to include the information about the timezone when transmitting times... it gets tricky to parse when they don't, especially in places that change their timezone twice a year.

Michael Jones
  • 1,900
  • 5
  • 12
  • Yes, I tried that, but then I have to handle summer / winter time manually, don't I? So now it +02:00 but in half a year it would be only +01:00. This something I would like to avoid - or is there eventually a dw function to find out what time of year it is? – maco May 25 '21 at 15:01
  • @maco Does using the named timezone like aled suggested below work for you instead? Not familiar with CET. edit: I looked and it looks like it does oscillate from CET to CEST. Is the machine that will be running the DataWeave in the correct timezone? – Michael Jones May 25 '21 at 16:05
  • If you do CET and CEST it looks like it still parses correctly, which means Aled's solution should work too. – Michael Jones May 25 '21 at 16:17