toJson serialization behaves incorrectly for dates on Windows, Linux, and Android

[sync-by-unito]

We're testing round-tripping date properties in the dart SDK and noticed that json serialization behaves inconsistently. For example, the date -0001-01-01 00:00:00 - I.e. year 1 BCE is encoded as -001-01-01 00:00:00 on Apple platforms, but as empty string on Windows (looks like all dates equal to or below 0000-01-01 00:00:00 get encoded as empty on Windows).

The date 0000-01-01 00:00:00 gets encoded as 0000-01-01 00:00:00 on Apple platforms but 0-01-01 00:00:00 (note the lack of leading zeroes) and as 1905-06-06 18:35:44 on Android.

The date 27182104-21 00:00:00 gets encoded as 2016-09-19 11:52:32 on Android, but correctly on Apple platforms.

It is possible that there's also a bug in the dart SDK in the way we represent dates on some platforms, but I verified that the reported that it's a serialization bug on windows (Studio correctly visualizes the expected date) and non-negative/zero dates work just fine, so there are strong indications that the bug is in the to_json implementation in Core.

[sync-by-unito]

➤ Jonathan Reams commented:

At least on windows, the function that converts a time_t to a struct tm (which is what you use to format a date/time) considers timestamps less than zero to be an error. That's why its encoded as empty on windows. I imagine android has similar issues.

[sync-by-unito]

➤ Nikola Irinchev commented:

For prioritization purposes, I'd like to clarify that to_json is not a public API in the dart SDK and we're using it in tests to verify that the data that we pass in from dart matches the data that Core receives. It may be a public API in other SDKs though as I've seen some java tickets relating to it. cc [~[email protected]]

[sync-by-unito]

➤ Christan Melchior commented:

Kotlin is just using it internally for testing as well, and only for Credentials, so we are not checking anything around timestamps.

[sync-by-unito]

➤ James Stone commented:

[~[email protected]] can we change the format of timestamps printed for json, or is that going to break the E2E tests?

[sync-by-unito]

➤ Tyler Kaye commented:

It will affect our fuzz tests only, but we can make a change in how that is decoded fairly easily. This is just the realm2json tool?

[jedelbo]

@ironage @nirinchev Are we going to fix this any time soon or can we close this as a non-issue?

[nirinchev]

I'd rather that we fix it as that's the most convenient way to verify that the SDK and Core agree on what data is being stored.

[jedelbo]

The fix has been reverted

[jedelbo]

But now fixed by #6862