Reading a datetime string like 2022-04-26T16:49:20.877 UTC

[glennpierce]

I am trying to port some moment code where I read the datetime string "2022-04-26T16:49:20.877 UTC"

but I keep getting invalid datetime with the following

DateTime.fromFormat('2022-04-26T16:49:20.877 UTC', 'yyyy-MM-ddTHH:mm:ss.SSS ZZZZ').toLocaleString(DateTime.DATETIME_MED)

I thought it was the UTC but its not just that as I removed it to test. In my code in the browser debugger I get the error
unparsable

explanation: "the input "2022-04-26T16:49:20.877" can't be parsed as format yyyy-MM-ddTHH:mm:ss.SSS"

I am running "luxon": "^2.4.0",

Any idea what I am doing wrong ?

[icambron]

T is a token for "localized 24-hour time". See https://moment.github.io/luxon/#/parsing?id=table-of-tokens. You'll need to quote it like 'T' so that it's taken literally instead of as a token.

For debugging this kind of thing, use DateTime.fromFormatExplain() which will show you the individual tokens. If you do that, you'll see that your T expanded to several tokens in the middle of your format:

tokens: [
  // snip
  {literal: false, val: 'dd'} // <-- this is your "dd"
  {literal: false, val: 'h'} // <-- h, :, and m are the expansion of T
  {literal: true, val: ':'}
  {literal: false, val: 'm'}
  {literal: false, val: 'HH'} // <-- this is your HH
  // snip
]

[glennpierce]

Thanks I just this second worked it out

DateTime.fromFormat(fields[0], "yyyy-MM-dd'T'HH:mm:ss.SSS 'UTC'").toUTC();

Still can't match Utc with the ZZZZ though

[icambron]

yeah, you want z, not ZZZZ. In formatting, ZZZZ means like "Eastern Standard Time" or "British Summer Time". It can't be parsed though, for reasons explained in the zones documentation:

A named offset is a time zone-specific name for an offset, such as Eastern Daylight Time. It expresses both the zone (America's EST roughly implies America/New_York) and the current offset (EST means -5). They are also confusing in that they overspecify the offset (e.g. for any given time it is unnecessary to specify EST vs EDT; it's always whichever one is right). They are also ambiguous (BST is both British Summer Time and Bangladesh Standard Time), unstandardized, and internationalized (what would a Frenchman call the US's EST?). For all these reasons, you should avoid them when specifying times programmatically. Luxon only supports their use in formatting.

But UTC is also a valid zone specifier, so you can parse it with z the same way you could, say, "America/New_York"

DateTime.fromFormat("2022-04-26T16:49:20.877 UTC", "yyyy-MM-dd'T'HH:mm:ss.SSS z").toISO() //=> '2022-04-26T12:49:20.877-04:00'

[glennpierce]

Thanks