You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following integration tests will fail when they are run on a machine with a GMT+2 time zone, they pretty much explain the problem:
When we get a recently added task, or any task in general, the DueDate.Date property works as expected but the DueDate.StringDate property shifts time by the local time zone offset.
[Fact]publicasyncTaskCreatedTask_ShouldReturnMatchingDueDate_WhenWeGetItById(){// Arrangevarclient=newTodoistClient(TodoistAccessToken);varitem=newItem("Task with time"){DueDate=newDueDate("22 Dec 2021 at 9:15",language:Language.English)};// Actawaitclient.Items.AddAsync(item);varitemInfo=awaitclient.Items.GetAsync(item.Id);try{// AssertAssert.Equal(newDateTime(2021,12,22,9,15,0),itemInfo.Item.DueDate.Date);// SucceedsAssert.Equal("2021-12-22T09:15:00",itemInfo.Item.DueDate.StringDate);// Fails: StringDate returns 2021-12-22T07:15:00}finally{// Cleanupawaitclient.Items.DeleteAsync(item.Id);}}
When we get a task and then update it with no changes at all, the due date will change the same way that DueDate.StringDate did in the last test, and again, DueDate.StringDate will shift time by additional two hours.
[Fact]publicasyncTaskUpdatedTask_ShouldReturnMatchingDueDate_WhenNoChangesAreMade(){// Arrangevarclient=newTodoistClient(TodoistAccessToken);varitem=newItem("Task with time"){DueDate=newDueDate("22 Dec 2021 at 9:15",language:Language.English)};// Actawaitclient.Items.AddAsync(item);varitemInfo=awaitclient.Items.GetAsync(item.Id);awaitclient.Items.UpdateAsync(itemInfo.Item);itemInfo=awaitclient.Items.GetAsync(item.Id);try{// AssertAssert.Equal(newDateTime(2021,12,22,9,15,0),itemInfo.Item.DueDate.Date);// Fails: Date returns 22/12/2021 07:15:00Assert.Equal("2021-12-22T09:15:00",itemInfo.Item.DueDate.StringDate);// Fails: StringDate returns 2021-12-22T05:15:00}finally{// Cleanupawaitclient.Items.DeleteAsync(item.Id);}}
This problem occurs in general when the task contains a floating due date, the date is treated like a local time when being converted from DateTime to string in the DueDate.StringDate property getter, hence, its string value changes from what it was given by the API.
In the previous tests, the value "2021-12-22T09:15:00" fetched from the API was converted to a DateTime of kind DateTimeKind.Unspecified, and then converted back to "2021-12-22T07:15:00" when sent back to the API for update.
That results in an unwanted update on the task without even changing any field.
The text was updated successfully, but these errors were encountered:
Which is not problematic on its own, but combined with the getter's DateTime.Parse, the date given by the API is converted to date with kind DateTimeKind.Unspecified in case it's a floating due date, which is then converted to Utc date in the setter.
I will now open a pull request for the fix I've just made on my fork.
The following integration tests will fail when they are run on a machine with a GMT+2 time zone, they pretty much explain the problem:
DueDate.Date
property works as expected but theDueDate.StringDate
property shifts time by the local time zone offset.DueDate.StringDate
did in the last test, and again,DueDate.StringDate
will shift time by additional two hours.This problem occurs in general when the task contains a floating due date, the date is treated like a local time when being converted from
DateTime
tostring
in theDueDate.StringDate
property getter, hence, its string value changes from what it was given by the API.In the previous tests, the value
"2021-12-22T09:15:00"
fetched from the API was converted to aDateTime
of kindDateTimeKind.Unspecified
, and then converted back to"2021-12-22T07:15:00"
when sent back to the API for update.That results in an unwanted update on the task without even changing any field.
The text was updated successfully, but these errors were encountered: