René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"SetAndReadDateTimeLocal_DateRange test fails due to DST changes in America/Sao_Paulo timezone","articleBody":"Below is what happens on my PT-BR system. Compiled against v8-v142 (7.5.288.23), target net45. \r\n\r\nSince the test case runs through the all dates at 0:00, it receives back 1:00 AM when it hits\r\nDST shift time in Brazil (and other local time adjustments like the one in 1914).  This is the expected behavior for V8, since such combinations of date/time does not exist in America/Sao_Paulo timezone.\r\n\r\n```\r\nMessage: \r\n    Assert.Fail failed. Expected 01/01/1914 00:00:00, but got 01/01/1914 00:06:28\r\n    Expected 03/10/1932 00:00:00, but got 03/10/1932 01:00:00\r\n    Expected 01/12/1949 00:00:00, but got 01/12/1949 01:00:00\r\n    Expected 01/12/1950 00:00:00, but got 01/12/1950 01:00:00\r\n    Expected 01/12/1951 00:00:00, but got 01/12/1951 01:00:00\r\n    ....\r\n    Expected 16/10/2016 00:00:00, but got 16/10/2016 01:00:00\r\n    Expected 15/10/2017 00:00:00, but got 15/10/2017 01:00:00\r\n    Expected 04/11/2018 00:00:00, but got 04/11/2018 01:00:00\r\n    Expected 03/11/2019 00:00:00, but got 03/11/2019 01:00:00\r\n    ....\r\n    Expected 03/11/2097 00:00:00, but got 03/11/2097 01:00:00\r\n    Expected 02/11/2098 00:00:00, but got 02/11/2098 01:00:00\r\n    Expected 01/11/2099 00:00:00, but got 01/11/2099 01:00:00\r\n```\r\n\r\nI added val.toString() and val.getTime() to the test output, so I could verify that V8 Date objects are correct. Here is what I got back:\r\n\r\n```\r\n....\r\n    Expected 16/10/2016 00:00:00, but got 16/10/2016 01:00:00 \r\n    str: Sun Oct 16 2016 01:00:00 GMT-0200 (Horário de Verão de Brasília), \r\n    timestamp: 1476586800000\r\n\r\n    Expected 15/10/2017 00:00:00, but got 15/10/2017 01:00:00 \r\n    str: Sun Oct 15 2017 01:00:00 GMT-0200 (Horário de Verão de Brasília), \r\n    timestamp: 1508036400000\r\n....\r\n```\r\n\r\nIt is exactly the same behavior as I get in chrome console for that dates:\r\n\r\n```\r\n\u003enew Date(2016,9,16)\r\n\u003cSun Oct 16 2016 01:00:00 GMT-0200 (Horário de Verão de Brasília)\r\n\u003e1476586800000\r\n```\r\n\r\nSo the problem is with the test itself, as long as you are only dealing with local (timezone-unaware) DateTime objects. However, it will be a different story for timezone-aware DateTime objects (those with timezone information).\r\n\r\nIn 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). \r\n","author":{"url":"https://github.com/m0nzderr","@type":"Person","name":"m0nzderr"},"datePublished":"2019-09-24T20:30:09.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/82/Javascript.Net/issues/82"}