devdocs/todo.txt

@@ -193,7 +193,7 @@ However if I want "next month" then that's relative to my personal location, I c
 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.
-
+SOLUTION: provide the relative time offset to the sql criteria builder for CURRENT USER, sql criteria builder will factor it into all the NOW values determined.
 
 =================
 
@@ -203,6 +203,8 @@ TESTING TODO - Are all tests viable with a huge dataset, try locally and rejig t
 TESTING TODO - All date ranges should be on exact boundaries to ensure that all boundary date code in criteria builder is correct
 SQL Criteria builder - Should it really be backing off a second for boundary edges?  That will mean items that are less than a second but more than zero seconds will 
 be included whenb they shouldn't.  If the sql server has 1 millesecond accuracy then it should be backed off one millisecond surely?
+TESTING TODO - Re-test v7 user import, I added some code for timezone and ui color etc needs to be confirmed wont' bomb on nulls etc
+
 
 
 INITIAL TESTING NOTES: