localDatetime timezone discrepancy in iso8601 format

[rdhar]

Summary

There is no difference in output between datetime and localDatetime in iso8601 format. I would expect the local timezone to be taken into account for localDateTime.

Replication Steps

Using PostBin as a free API client to test requests using this script:

POST https://postb.in/###?
  &iso8601_datetime={{$datetime iso8601}}
  &iso8601_localDatetime={{$localDatetime iso8601}}
  &rfc1123_datetime={{$datetime rfc1123}}
  &rfc1123_localDatetime={{$localDatetime rfc1123}}

Expected Behavior

In the UK, which is currently observing UTC +1 timezone.

Variable	Format	Result
$datetime	iso8601	2020-07-28T14:30:00.000Z
$localDatetime	iso8601	2020-07-28T15:30:00.000+01:00

Actual Behavior

In the UK, which is currently observing UTC +1 timezone.

Variable	Format	Result
$datetime	iso8601	2020-07-28T14:30:00.000Z
$localDatetime	iso8601	2020-07-28T14:30:00.000Z

For comparison, this difference is reflected correctly in rfc1123 format.

Variable	Format	Result
$datetime	rfc1123	Tue, 28 Jul 2020 14:30:00 GMT
$localDatetime	rfc1123	Tue, 28 Jul 2020 15:30:00 0100

Thanks for your time and effort for this extension and wish you the best with development on #628!

Version

REST Client	VS Code	OS
v0.24.1	v1.47.3	Windows 10 v2004

[Huachao]

@rdhar nice catch, I have fixed it, and before I publish a new version, you can try the format like following to achieve this {{$localDatetime 'YYYY-MM-DDTHH:mm:ss.SSSZ'}} with a specified format string.

[rdhar]

Thanks for such a prompt response, @Huachao, really appreciate it! Current behaviour is as follows:

Variable	Format	Result
$datetime	iso8601	2020-07-28T14:30:00.000Z
$localDatetime	iso8601	2020-07-28T14:30:00.000Z
$localDatetime	YYYY-MM-DDTHH:mm:ss.SSSZ	2020-07-28T15:30:00.000 01:00

This is much closer to the expected value, with exception to the missing timezone signage i.e., +01:00. Without the +/−, there is no basis for relation with UTC so it's not a valid ISO 8601 timezone designator representation.

I understand you're using Day.js, where the relevant docs page for Local time appears to suggest that a signed timezone is possible with:

dayjs.extend(utc);

var a = dayjs.utc();
a.format(); // 2019-03-06T00:00:00Z
a.local().format(); //2019-03-06T08:00:00+08:00

Wonder if this would be possible to leverage the output for {{$localDateTime iso8601}}?

[Huachao]

@rdhar I will use your suggestion, however, the format YYYY-MM-DDTHH:mm:ss.SSSZ works on my machine

[rdhar]

Oh, in that case, I wonder if the issue is on my end. Sorry if I've caused a hassle, I'll double-check my output to be sure.

What's your output for YYYY-MM-DDTHH:mm:ss.SSSZ and your local timezone and how does this compare after your latest commit ba88dcb?

EDIT: Double-checked to find I was reading the output incorrectly. I'm sorry about the confusion!

When the variables are sent as query parameters, signs are removed/replaced with whitespace. Presumably, this is part of URL encoding(?).

Cross-checked screenshots across PostBin and PutsReq…

PostBin:

PutsReq:

Here's the correct behaviour output altogether:

Variable	Format	Output
datetime	rfc1123	Tue, 28 Jul 2020 14:30:00 GMT
datetime	iso8601	2020-07-28T14:30:00.000Z
localDatetime	rfc1123	Tue, 28 Jul 2020 15:30:00 +0100
localDatetime	iso8601	2020-07-28T14:30:00.000Z
localDatetime	YYYY-MM-DDTHH:mm:ss.SSSZ	2020-07-28T15:30:00.000+01:00

Where YYYY-MM-DDTHH:mm:ss.SSSZ is a perfectly viable workaround for displaying localDateTime in iso8601. Thank you!

[Huachao]

@rdhar you can try the latest version 0.24.2

[rdhar]

The results are perfect, as shown in the screenshot from Postb.in below. Many thanks once again for your prompt resolution, @Huachao!