This commit is contained in:
@@ -148,6 +148,53 @@ Here at this server locally they are starting out in pacific time and then conve
|
||||
Will need the debug log of the query built to see what the what next
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Working (localhost) next month filter log:
|
||||
2018-12-10 08:39:49.3954|INFO|WidgetBiz::GetManyAsync|Filter criteria:
|
||||
2018-12-10 08:39:49.3954|INFO|WidgetBiz::GetManyAsync|[
|
||||
{
|
||||
"fld": "name",
|
||||
"op": "%-",
|
||||
"value": "DateTokenNextMonthFilterWorks"
|
||||
},
|
||||
{
|
||||
"fld": "startdate",
|
||||
"op": "=",
|
||||
"value": "{[nextmonth]}"
|
||||
}
|
||||
]
|
||||
2018-12-10 08:39:49.3954|INFO|WidgetBiz::GetManyAsync|Generated SQL:
|
||||
2018-12-10 08:39:49.4126|INFO|WidgetBiz::GetManyAsync|SELECT *, xmin FROM AWIDGET where name Like 'DateTokenNextMonthFilterWorks%' AND startdate >'2019-01-01T07:59:59.0000000Z' AND startdate <'2019-02-01T08:00:00.0000000Z'
|
||||
2018-12-10 08:39:49.4248|WARN|Microsoft.EntityFrameworkCore.Query|Query: '(from Widget <generated>_4 in DbSet<Widget> select [<generated>_4]).Skip(__p_1).Take(__p_2)' uses a row limiting operation (Skip/Take) without OrderBy which may lead to unpredictable results.
|
||||
|
||||
SERVER DEVOPS VERSION:
|
||||
2018-12-10 16:46:25.5657|INFO|WidgetBiz::GetManyAsync|Filter criteria:
|
||||
2018-12-10 16:46:25.5657|INFO|WidgetBiz::GetManyAsync|[
|
||||
{
|
||||
"fld": "name",
|
||||
"op": "%-",
|
||||
"value": "DateTokenNextMonthFilterWorks"
|
||||
},
|
||||
{
|
||||
"fld": "startdate",
|
||||
"op": "=",
|
||||
"value": "{[nextmonth]}"
|
||||
}
|
||||
]
|
||||
2018-12-10 16:46:25.5657|INFO|WidgetBiz::GetManyAsync|Generated SQL:
|
||||
2018-12-10 16:46:25.5657|INFO|WidgetBiz::GetManyAsync|SELECT *, xmin FROM AWIDGET where name Like 'DateTokenNextMonthFilterWorks%' AND startdate >'2018-12-31T23:59:59.0000000Z' AND startdate <'2019-02-01T00:00:00.0000000Z'
|
||||
2018-12-10 16:46:25.5733|WARN|Microsoft.EntityFrameworkCore.Query|Query: '(from Widget <generated>_4 in DbSet<Widget> select [<generated>_4]).Skip(__p_1).Take(__p_2)' uses a row limiting operation (Skip/Take) without OrderBy which may lead to unpredictable results.
|
||||
|
||||
WHAT IS HAPPENING
|
||||
what is happening is that the data is converted to UTC before sending to the server, the server is supposed to be a dumb date unaware repository
|
||||
However if I want "next month" then that's relative to my personal location, I can't go by the server's next month because that is in UTC and I'm not.
|
||||
So for the server to process *my* next month it needs to know what my relative time offset is.
|
||||
I've decided to never trust the client for current time zone information and use an independent setting for the user account.
|
||||
So the relative time query builders need to use the relative offset in the production of the NOW date that everything keys off of.
|
||||
|
||||
|
||||
=================
|
||||
|
||||
|
||||
@@ -233,7 +280,7 @@ SERVER
|
||||
|
||||
- Delete user should delete private datafilters
|
||||
- Did I code how to handle implications of user delete anywhere yet??
|
||||
|
||||
- LOG File names, when logs are rotated, I'm seeing the number 18 and 17 in the devops log file rotated names?! Shouldn't it just be 1 to 3 or something, will that number keep growing infinitely?
|
||||
|
||||
|
||||
- Stage 2 AFTER POSTED TEST ROUND COMPLETED
|
||||
|
||||
Reference in New Issue
Block a user