NightOwl888 commented on issue #772: URL: https://github.com/apache/lucenenet/issues/772#issuecomment-1329023673
The time zone parameter was recently added. This is to align with the Java DateFormat which allows for the time zone to be changed. We don't have a complete port of DateFormat (not very sensible in .NET), but the flexible QueryParser uses [`NumericDateFormat`](https://github.com/apache/lucenenet/blob/master/src/Lucene.Net.QueryParser/Flexible/Standard/Config/NumberDateFormat.cs) to convert the date to a number, which uses this format. In Lucene, this accepted a DateFormat as a parameter, but we made a hybrid implementation instead since .NET has no such animal. There is DateTimeFormatInfo, but it doesn't provide the expected functionality. I also attempted to make `DateTime` work, but `DateTimeOffset` seems to be the only thing in .NET that lets you specify a timezone other than Local or UTC and then converted into the expected string. Refer to https://github.com/dotnet/runtime/issues/62247 to understand the limitations of the .NET time zone feature. The problem you are seeing is that in .NET the `DateTime` defaults to 0001-01-0001, but in Java the Date class defaults to 1970-01-01 (both midnight UTC). The default .NET date cannot be represented with a time zone because time zones hadn't been invented yet (they are political, not geographical). But in Java, the default works fine because it is within the expected range. 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. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
