NightOwl888 commented on issue #772: URL: https://github.com/apache/lucenenet/issues/772#issuecomment-1329067396
> The answer to solving this lies in the .NET source code. I see there is an enum value that allows suppression of an invalid time zone so it doesn't throw. We need to use the same validation logic to ensure we don't call the time zone conversion functions when it is out of range. What to do instead isn't quite clear to me yet. But a guess would be to call the date.ToString() method like we did [in beta 00015](https://github.com/apache/lucenenet/blob/Lucene.Net_4_8_0_beta00015/src/Lucene.Net/Document/DateTools.cs). However, that doesn't shift the time zone appropriately. > > Perhaps we should do the time zone conversion on the current date to get a timespan (difference from UTC), then use that to create a new DateTimeOffset(date, offset).ToString(CultureInfo.InvariantCulture) on that. That is, only in the case where it is out of range to be considered a valid timezone. When it is in range, the current code works fine. On second thought, whatever they are doing in the .NET source code when they suppress the error is probably the right answer for what we need to do. Again, only in the case where we are out of range. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
