SetAndReadDateTimeLocal_DateRange test fails due to DST changes in America/Sao_Paulo timezone about javascript.net

[spahnke]

The reason why we do the conversion in a component wise fashion is because V8 does use the IANA timezone database and C# does not. Leading to inherent discrepancies explained in #75 and #76 .

In order to have stable behavior across different locales, I recommend to avoid component-based Date conversion. Instead, it would be better to always have any .NET DateTime object first converted to UTC timestmp (locaized or not), an then use this timestamp to construct V8 Date constructor (it could be int64 value or ISOString).

I think that's basically what we tried with #55 IIRC which had the nasty bugs explained in the other two PRs.

The brute-force test was more or less an assurance for me while writing the conversion, that I don't miss any more edge cases where C# and V8 disagree. So it's not the best test anyway, especially since you can't fix a timezone while running a test. (See #76 for more timezones where the brute-force test was known to fail)

I do not pretend to understand this topic completely in all its details but this was the closest we could get. If you find a better solution where the existing tests still pass you're welcome to create a PR 🙇