Non-valid .toISOString(), must include 'Z' at the end

[warmrobot]

https://github.com/date-fns/tz/blob/main/src/date/index.js#L29-L30

And there is no seconds, by the way

[GianlucaWassermeyer]

Hello,

The 'Z' indicates that the ISOString is in Zulu time (UTC). He uses the variant with the timezone offset inside the ISOString for TZDate, which is just as valid as the other format. Furthermore, JavaScript Date does not accept any timezone offsets with seconds; it would be an invalid ISOString.

[sovcik]

Well, as format is is valid to have both "Z" and "+00:00", but it differs from what Javascript toISOString should do:

1. datetime is always UTC
2. suffix is always "Z"
   see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString

I actually like TZDate approach more - never really understood why toISOString changes timezone too, but that's how it is... and if TZDate's goal is to be fully compatible, then this should be fixed.

[GianlucaWassermeyer]

If you don´t like the toISOString() from TZDate, you can use TZDateMini as a workaround. That´s what I use in my project to always return an ISOString with Z.

[mindplay-dk]

Yeah, I immediately noticed this issue.

2025-04-28T06:40:20.782+00:00 should be 2025-04-28T06:40:20.782Z for consistency.

The Z notation saves bytes in transport over JSON, and most tools will use that format for UTC timestamps.

But if nothing else, I think this should be corrected just to avoid questions about it. Many tools exchange date/time exclusively in UTC and use nothing but the Z notation, and date/time management is confusing is enough as it is.

There is something to be said for TZDateMini and TZDate being as consistent as possible, too, right?

It's not clear to me why TZDate would need to override toISOString in the first place? TZDate and TZDateMini both produce the same result for toISOString, do they not? And for that matter, the same as the native Date function - doesn't it?

[zhouzh1]

FYI: maybe you guys can try the change in this PR, I was hit by a similar issue after upgraded to the v1.2.0, this PR resolved the problem for me. cc @mindplay-dk

[mindplay-dk]

@zhouzh1 I don't understand what setTime has to do with toISOString?

I also don't understand why the library would even need to override setTime in the first place?

setTime and getTime is the number of milliseconds since the epoch, no matter the time zone, is it not?

[zhouzh1]

In this library, there are such kinds of method invocations like Date.prototype.setFullYear.call(date, ...), and here the date argument is of the TZDateMini type, however, in the native setFullYear method internal, it will call the this.setTime method to set the number of milliseconds since the epoch, but you know, due to the JavaScript function context binding, so finally it actually calls the overriden setTime method in the TZDateMini class, that's not expected and will cause a wrong transformation between the region time and UTC time, because in the overriden setTime method, there is an extra syncToInternal invocation. Back to the toISOString method, it actually relies on the correct time transformation as well, so it gets affected here.

Hope my above statements help you. @mindplay-dk

[mindplay-dk]

@zhouzh1 tbh I still don't really understand, though I think my confusion is more about the library itself... I never looked at the whole implementation until just now, and I don't understand why it's implemented this way in the first place. Why would a timezone aware version of Date be more than an added timezone property, overrides for getDate(), getMonth(), etc. plus the toString override? Everything else should be the same, shouldn't it? It looks really complicated. 😵‍💫

[zhouzh1]

@mindplay-dk Well, seems that we're not talking about the same problem, I thought you meant the toISOString method is returning a wrong value for date and time, however actually your concern is just about the result format. Sorry for the confusion.

[Sebi11]

I guess this is a duplicate of: #15