[API enhancement]: Add TimeSpan to DateTimeOffset to be aware of DST switch and chosen timezone

[Zeruxky]

Is the feature request related to a problem

At the current state of FluentDateTime, all operations do not respect the timezone chosen by the user. The system where the application runs decides which timezone is being used. On default, this is TimeZoneInfo.Local. This leads to the two following problems:

1. Any user of FluentDateTime can not decide in which timezone he wants to operate on. For example, your application runs on servers in Germany (CEST timezone) and your customer operates from Britain (GMT / UTC timezone). If you for example want to add a given TimeSpan (for example +1h), you are operating in the timezone of the server and not of your customer.
2. Also, you don't have the option to respect the switches from standard time to daylight saving time (DST) and vise versa, because Add() and all convenience methods on DateTimeOffset (AddMonths(), AddDays(), …) are not aware of these switches.

Describe the solution

For the first step, I would propose an extension method Add which operates on DateTimeOffset, but considers the TimeZoneInfo chosen by the user. So the API would look like the following:

public static class DateTimeOffsetExtensions
{
    public static DateTimeOffset Add(this DateTimeOffset dateTimeOffset, TimeSpan interval, TimeZoneInfo timeZoneInfo);
}

To provide legacy support for the current API, the TimeZoneInfo parameter can be made nullable and initialized with null, which results in utilizing the TimeZoneInfo.Local. This does not change the current behavior implemented in FluentDateTime.

From this on, we can implement new methods that respect the user defined TimeZoneInfo and refactor the existing API to support (DST switches) which makes FluentDateTime more usable for scenarios where different timezones are used.

Describe alternatives considered

If you don't want to change the current, existing API and functionality, it would be also possible to add additional methods AddInTimeZone(), AddHoursInTimeZone(), and so on. This does not affect other methods and would only introduce new additional methods.

Additional context

I'm open to contribute this change by submitting a PR and also taking any considerations by you or any other participant.

Best regards
Philip