Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add BaseUtcOffset to TimeZoneInfo.AdjustmentRule. #50256

Closed
tarekgh opened this issue Mar 25, 2021 · 6 comments · Fixed by #51055
Closed

Add BaseUtcOffset to TimeZoneInfo.AdjustmentRule. #50256

tarekgh opened this issue Mar 25, 2021 · 6 comments · Fixed by #51055
Assignees
Labels
api-approved API was approved in API review, it can be implemented area-System.DateTime
Milestone

Comments

@tarekgh
Copy link
Member

tarekgh commented Mar 25, 2021

This proposal edited to address the feedback we got in the design review

Background and Motivation

TimeZoneInfo.Adjustment provides information about a time zone adjustment, such as the transition to and from daylight saving time. every adjustment rule has a start and end dates to describe at what date and time the rule can apply. Although the rule provides the information that help convert from the local time to UTC and vice versa, but it lacks an essential information which is what is the base UTC offset for the time zone during the rule period. TimeZoneInfo originally assumed that the base UTC offset for the zone is constant and never change which is incorrect. There are zones changed the UTC offset at some point.

The proposal here is have the AdjustmentRule class provide a property telling what the base UTC offset delta of the zone during the rule start and end date is.

Proposed API

    public sealed partial class TimeZoneInfo
    {
        public sealed class AdjustmentRule : IEquatable<AdjustmentRule?>, ISerializable, IDeserializationCallback
        {
             public TimeSpan BaseUtcOffsetDelta { get; }

             public static TimeZoneInfo.AdjustmentRule CreateAdjustmentRule(
                              DateTime dateStart, 
                              DateTime dateEnd, 
                              TimeSpan daylightDelta, 
                              TimeZoneInfo.TransitionTime daylightTransitionStart, 
                              TimeZoneInfo.TransitionTime daylightTransitionEnd, 
                              TimeSpan baseUtcOffsetDelta); // this is the only added parameter compared to the other overload.
        }
    }

Usage Examples

    // On 27 March 2011, Russia moved to year-round daylight-saving time. Instead of switching between UTC+09:00 in winter and UTC+10:00 in summer, 
    // Yakutsk Time became fixed at UTC+10:00 until 2014, when it was reset back to UTC+09:00 year-round.
    TimeZoneInfo tzi = TimeZoneInfo.FindSystemTimeZoneById("Asia/Yakutsk");
    foreach (TimeZoneInfo.AdjustmentRule rule in tzi.GetAdjustmentRules())
    {
        Console.WriteLine($"Base Utc offset during the time {rule.DateStart} and {rule.DateEnd} is {tzi.BaseUtcOffset + rule.BaseUtcOffsetDelta}");
    }
@tarekgh tarekgh added area-System.Runtime blocking Marks issues that we want to fast track in order to unblock other important work api-ready-for-review API is ready for review, it is NOT ready for implementation labels Mar 25, 2021
@tarekgh tarekgh added this to the 6.0.0 milestone Mar 25, 2021
@tarekgh tarekgh self-assigned this Mar 25, 2021
@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Mar 25, 2021
@tarekgh
Copy link
Member Author

tarekgh commented Mar 25, 2021

CC @mattjohnsonpint

@Clockwork-Muse
Copy link
Contributor

TimeZoneInfo originally assumed that the base UTC offset for the zone is constant and never change which is incorrect. There are zones changed the UTC offset at some point.

Heh. Pretty much every timezone has an offset change from local solar noon to the first discrete offset. How are you anticipating these being represented?

@tarekgh
Copy link
Member Author

tarekgh commented Mar 25, 2021

@Clockwork-Muse we just read the rules data from the OS. Whatever offsets giving there we'll use it. We just expose that data we read.

@terrajobst terrajobst removed api-ready-for-review API is ready for review, it is NOT ready for implementation blocking Marks issues that we want to fast track in order to unblock other important work untriaged New issue has not been triaged by the area owner labels Mar 26, 2021
@terrajobst
Copy link
Member

terrajobst commented Mar 26, 2021

Video

  • We probably want an overload for CreateAdjustmentRule that allows people to construct an instance with an offset
  • We need to think about what this means for instances that were created without an offset. Should it be nullable?
namespace System
{
   public partial class TimeZoneInfo
   {
        public partial class AdjustmentRule
        {
            public TimeSpan BaseUtcOffset { get; }
            public static AdjustmentRule CreateAdjustmentRule(
                DateTime dateStart,
                DateTime dateEnd,
                TimeSpan daylightDelta,
                TransitionTime daylightTransitionStart,
                TransitionTime daylightTransitionEnd,
                TimeSpan baseUtcOffset
            );
         }
    }
}

@terrajobst terrajobst added the api-needs-work API needs work before it is approved, it is NOT ready for implementation label Mar 26, 2021
@mattjohnsonpint
Copy link
Contributor

Agree we need parameter on CreateAdjustmentRule. Options are either TimeSpan? baseUtcOffset or TimeSpan baseUtcOffsetDelta.

@tarekgh tarekgh added api-ready-for-review API is ready for review, it is NOT ready for implementation blocking Marks issues that we want to fast track in order to unblock other important work and removed api-needs-work API needs work before it is approved, it is NOT ready for implementation labels Mar 29, 2021
@terrajobst terrajobst added api-approved API was approved in API review, it can be implemented and removed api-ready-for-review API is ready for review, it is NOT ready for implementation blocking Marks issues that we want to fast track in order to unblock other important work labels Apr 1, 2021
@terrajobst
Copy link
Member

  • Looks good as proposed
namespace System
{
   public partial class TimeZoneInfo
   {
        public partial class AdjustmentRule
        {
            public TimeSpan BaseUtcOffsetDelta { get; }

            // Existing method:
            // public static AdjustmentRule CreateAdjustmentRule(
            //     DateTime dateStart,
            //     DateTime dateEnd,
            //     TimeSpan daylightDelta,
            //     TransitionTime daylightTransitionStart,
            //     TransitionTime daylightTransitionEnd
            // );

            public static AdjustmentRule CreateAdjustmentRule(
                DateTime dateStart,
                DateTime dateEnd,
                TimeSpan daylightDelta,
                TransitionTime daylightTransitionStart,
                TransitionTime daylightTransitionEnd,
                TimeSpan baseUtcOffsetDelta
            );
         }
    }
}

@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Apr 10, 2021
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Apr 13, 2021
@ghost ghost locked as resolved and limited conversation to collaborators May 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-approved API was approved in API review, it can be implemented area-System.DateTime
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants