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

Period.Between can report partially-negative values #824

Closed
jskeet opened this Issue May 20, 2017 · 3 comments

Comments

Projects
None yet
1 participant
@jskeet
Member

jskeet commented May 20, 2017

This isn't meant to happen...

Reported on http://stackoverflow.com/questions/44087757

var start = DateTime.Now;
var end = start.AddDays(7).AddMinutes(-1);
        
var period = Period.Between(LocalDateTime.FromDateTime(start), LocalDateTime.FromDateTime(end));
Console.WriteLine(period); // P6DT24H-1M

More investigation required.

@jskeet jskeet added the bug label May 20, 2017

@jskeet jskeet self-assigned this May 20, 2017

@jskeet

This comment has been minimized.

Member

jskeet commented May 20, 2017

Version without DateTime:

var start = new LocalDateTime(2017, 5, 20, 18, 49, 30)
    .PlusTicks(4498940);
var end = start.PlusDays(7).PlusMinutes(-1);
var period = Period.Between(start, end);
Console.WriteLine(period);
@jskeet

This comment has been minimized.

Member

jskeet commented May 20, 2017

Even a simple example is broken in 2.0:

var start = new LocalDateTime(2017, 5, 20, 18, 49, 30);
var end = start.PlusDays(1).PlusMinutes(-30);
        
var period = Period.Between(start, end);
Console.WriteLine(period);

... but it works in 1.3. I think this is broken for every period which should have "23 hours and a bit".

@jskeet

This comment has been minimized.

Member

jskeet commented May 20, 2017

It's worse than that - I think it's broken for all periods where the end time is later than the start time :( Definitely an urgent fix, and will require a 2.0.2 as soon as it is fixed. (The good news is it's quite a localized bug, but I need sleep before I can fix it, I think.)

jskeet added a commit to jskeet/nodatime that referenced this issue May 21, 2017

Fix Period computation bug
The approach taken before was fundamentally unsound. It's clearer to
consider that when we get down to time-based fields, they're all
fixed-length, so we only need to consider the duration between the
start and end points. This is an initial fix to patch into 2.0.2 -
it's not as efficient as it might be, but it's reasonably minimal.

Further refactoring will come in a separate PR, but that can stay on
the master branch only.

Fixes nodatime#824.

@jskeet jskeet closed this in #825 May 22, 2017

jskeet added a commit that referenced this issue May 22, 2017

Fix Period computation bug
The approach taken before was fundamentally unsound. It's clearer to
consider that when we get down to time-based fields, they're all
fixed-length, so we only need to consider the duration between the
start and end points. This is an initial fix to patch into 2.0.2 -
it's not as efficient as it might be, but it's reasonably minimal.

Further refactoring will come in a separate PR, but that can stay on
the master branch only.

Fixes #824.

jskeet added a commit to jskeet/nodatime that referenced this issue May 22, 2017

Fix Period computation bug
The approach taken before was fundamentally unsound. It's clearer to
consider that when we get down to time-based fields, they're all
fixed-length, so we only need to consider the duration between the
start and end points. This is an initial fix to patch into 2.0.2 -
it's not as efficient as it might be, but it's reasonably minimal.

Further refactoring will come in a separate PR, but that can stay on
the master branch only.

Fixes nodatime#824.

jskeet added a commit that referenced this issue May 22, 2017

Fix Period computation bug
The approach taken before was fundamentally unsound. It's clearer to
consider that when we get down to time-based fields, they're all
fixed-length, so we only need to consider the duration between the
start and end points. This is an initial fix to patch into 2.0.2 -
it's not as efficient as it might be, but it's reasonably minimal.

Further refactoring will come in a separate PR, but that can stay on
the master branch only.

Fixes #824.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment