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

TimeZone.AtStartofDate for day with switch to DLS in Brazil #1524

Closed
Stoffelche opened this issue Apr 29, 2020 · 7 comments · Fixed by #1527
Closed

TimeZone.AtStartofDate for day with switch to DLS in Brazil #1524

Stoffelche opened this issue Apr 29, 2020 · 7 comments · Fixed by #1527
Assignees
Labels
Milestone

Comments

@Stoffelche
Copy link

@Stoffelche Stoffelche commented Apr 29, 2020

In my code I have the following method:

public DateTime GetUtcStartOfDay(DateTime day) {
 return TimeZone.AtStartOfDay(new NodaTime.LocalDate(day.Year, day.Month, day.Day)).ToDateTimeUtc();
}

for 2012/10/21 I would assume that it returns UTC 2012-10-21-03:00 as the time is advanced in Brazil 1 hour but nothing happened yet with respect to UTC.

Then for the following day 2012/10/22 I would assume to get UTC 2012-10-22-02:00 as the missing hour leads to the shorter day 21.

However for 2012/10/21 I get instead: 2012-10-21-02:59:59.999, which is 1 ms less then expected.
This millisecond is already missing iin the AtStartOfDay result, so I assume something is wrong here?
For the following day 22 I get the full hour as expected.

Same applies for all other years for the day where the 1 hour is advanced.

BTW I use BclDateTimeZone.

@jskeet
Copy link
Member

@jskeet jskeet commented Apr 29, 2020

BTW I use BclDateTimeZone.

I suspect that's the problem. TimeZoneInfo behaves weirdly in all kinds of ways. I'll look into it - but I strongly suspect that if you use the TZDB data instead, it'll work fine.

@jskeet jskeet self-assigned this Apr 29, 2020
@jskeet jskeet added the bug label Apr 29, 2020
@jskeet
Copy link
Member

@jskeet jskeet commented Apr 29, 2020

Complete example:

using System;
using NodaTime;
using NodaTime.Text;

class Test
{
    static void Main()
    {
        var zone = DateTimeZoneProviders.Bcl["E. South America Standard Time"];
        var date = new LocalDate(2012, 10, 21);
        var zoned = zone.AtStartOfDay(date);
        Console.WriteLine(ZonedDateTimePattern.ExtendedFormatOnlyIso.Format(zoned));
    }
}

@jskeet
Copy link
Member

@jskeet jskeet commented Apr 29, 2020

I suspect the problem is that TimeZoneInfo uses "23:59:59.999" to represent a transition at midnight of the following day. I'll need to investigate whether our behavior actually matches TimeZoneInfo, or whether we just need to "round up".

@jskeet jskeet added this to the 3.0 milestone Apr 29, 2020
@Stoffelche
Copy link
Author

@Stoffelche Stoffelche commented Apr 29, 2020

for now I patched it the following way:

public DateTime GetUtcStartOfDay(DateTime day) {
	DateTime dt = TimeZone.AtStartOfDay(new NodaTime.LocalDate(day.Year, day.Month, day.Day)).ToDateTimeUtc();
// for Brazil on day of DLS switch TimeZon.AtStartOfDay looses a millisecond
	long seconds = dt.Ticks / TimeSpan.TicksPerSecond;
	if (seconds * TimeSpan.TicksPerSecond < dt.Ticks)
		dt = new DateTime((seconds + 1) * TimeSpan.TicksPerSecond, DateTimeKind.Utc);
	return dt;
}

jskeet added a commit to jskeet/nodatime that referenced this issue May 2, 2020
Transitions that would be represented as 24:00 in the IANA time zone database are represented as 23:59:59.999 in the Windows database. It makes sense to correct this as we have the facility to do so; the intent of the data is clearly "one millisecond later" even though that's not what the Windows rule actually says. (I don't think anyone would argue that the transition actually happens when the Windows rule says it does.)

Fixes nodatime#1524.
jskeet added a commit to jskeet/nodatime that referenced this issue May 2, 2020
Transitions that would be represented as 24:00 in the IANA time zone database are represented as 23:59:59.999 in the Windows database. It makes sense to correct this as we have the facility to do so; the intent of the data is clearly "one millisecond later" even though that's not what the Windows rule actually says. (I don't think anyone would argue that the transition actually happens when the Windows rule says it does.)

Fixes nodatime#1524.
jskeet added a commit to jskeet/nodatime that referenced this issue May 2, 2020
Transitions that would be represented as 24:00 in the IANA time zone database are represented as 23:59:59.999 in the Windows database. It makes sense to correct this as we have the facility to do so; the intent of the data is clearly "one millisecond later" even though that's not what the Windows rule actually says. (I don't think anyone would argue that the transition actually happens when the Windows rule says it does.)

Fixes nodatime#1524.
jskeet added a commit that referenced this issue May 2, 2020
Transitions that would be represented as 24:00 in the IANA time zone database are represented as 23:59:59.999 in the Windows database. It makes sense to correct this as we have the facility to do so; the intent of the data is clearly "one millisecond later" even though that's not what the Windows rule actually says. (I don't think anyone would argue that the transition actually happens when the Windows rule says it does.)

Fixes #1524.
@jskeet
Copy link
Member

@jskeet jskeet commented May 2, 2020

Thanks very much for raising this. It's fixed in master, and will go out as part of 3.0 (or the next beta). I won't be backporting it to 2.x.

@Stoffelche
Copy link
Author

@Stoffelche Stoffelche commented May 3, 2020

Thanks for fixing. When will v3.0 be released?

@jskeet
Copy link
Member

@jskeet jskeet commented May 3, 2020

I'm hoping it'll be reasonably soon - hopefully some time within May - but there are a few last bits of binary compatibility that we're looking at first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants