devdocs/specs/core-locale-currency-numbers-time-and-dates.txt

@@ -6,6 +6,24 @@ SERVER RESPONSIBILITIES FOR DATES AND TIME ZONES:
     - expects dates coming from client to be in UTC
     - Does take into account timezone offset when FILTERING a LIST for sending to the client that has a relative date filter like [NEXTMONTH]
         - This is the only place on the server where the user's time zone offset is used for anything
+  //************************ NOTE ABOUT TIME ZONES AND WHY I CHOSE TO USE A SELECTED OFFSET THE USER SETS RATHER THAN A TIME ZONE DESCRIPTOR
+                                //.NET CORE AYANOVA SERVER RUNNING ON LINUX VS WINDOWS MAY NOT HAVE ALL TIME ZONES DEFINED AND MAY ERROR OUT
+                                //THE ONLY SAFE WAY TO ENSURE CROSS PLATFORM TIME ZONE HANDLING FOR RELATIVE DATE FILTERS IS TO HAVE A HARD CODED TIME ZONE OFFSET 
+                                //THIS WAY USERS CAN SET IT AND IT'S INDEPENDENT OF ANY 3RD PARTY TIME ZONE DEFINITIONS ETC, MORE INFO HERE:
+                                //https://devblogs.microsoft.com/dotnet/cross-platform-time-zones-with-net-core/
+                                /*
+                                Time Zone differences
+
+Windows maintains its list of Time Zones in the Windows registry. You can find a list of those values here.
+
+In contrast, Linux distributions use the Time Zone database curated by the Internet Assigned Numbers Authority (IANA). You can find the latest copy of that database on IANA’s website. Here’s an example of what an IANA Time Zone looks like
+
+America/New_York
+
+The issue comes into play when you write your .NET Core code specifically using one of the two formats and then try to run the application on another operating system. Because the runtime is deferring the Time Zone management to the underlying operating system you will need to handle the differences if that scenario applies to you.
+                                */
+
+
 
 CLIENT RESPONSIBILITIES FOR DATES AND TIME ZONES
     - Send all datetime fields on records to the server in UTC

server/AyaNova/DataList/DataListSqlFilterCriteriaBuilder.cs

@@ -13,7 +13,6 @@ namespace AyaNova.DataList
     {
         public static string DataFilterToSQLCriteria(List<AyaDataListFieldDefinition> objectFieldsList, AyaNova.Models.DataListFilter dataFilter, List<AyaDataListFieldDefinition> objectFields, long userId)
         {
-            //BUGBUG: is using field property name not sql value column or whatever it's supposed to be
 
             if (string.IsNullOrWhiteSpace(dataFilter.Filter))
             {
@@ -305,25 +304,11 @@ namespace AyaNova.DataList
 
                             if (sValue.StartsWith("{[") && sValue.EndsWith("]}"))
                             {
- //BUGBUG: Ok, here's the issue:
-          //This test is run when my local time is winter time or "standard time" which is -8utc
-          //this test creates a future record for April which will be in DST or "daylight saving time" which is -7utc because it uses a library method to convert to universal time
-          //which takes into account the date. 
-          //In other words, test code is using conversions based on DST PST effective of the created date falls on
-
-          //At the server it's just blindly doing -8 because the user settings are at -8
-
-          //This means the server is filtering an april date using the forced -8 but the client is using the actual -7 so they are an hour out
-          //Fixes:
-          //Is it an issue?  User is normally going to select specific dates and times regardless of time zone so this client code is actually a bit off when you think of it that way
-          //So test client should take into account user options setting rather than local date setting?
-          //Or, should server instead of having hard coded offset just have user's time zone and it in turn does the calcs properly
-          //so local users doesn't select an offset but rather a time zone and let .net handle all the conversions
-          //In future there won't be a daylight saving time in pacific time zone likely
-          
+                              
 
                                 //Need to adjust RelativeToday to users time frame
                                 //Fetch useroptions object and relative time offset
+                                //See servers spec doc core-locale-currency-numbers-time-and-dates.txt for details about why this is necessary to be done this way
                                 AyaNova.Models.AyContext ct = AyaNova.Util.ServiceProviderProvider.DBContext;
                                 var u = ct.User.AsNoTracking().Where(a => a.Id == userId).Select(m => new { tz = m.UserOptions.TimeZoneOffset }).First();
 
@@ -474,9 +459,6 @@ namespace AyaNova.DataList
                                         break;
 
                                     case DataListFilterSpecialToken.NextMonth:
-                                        //BUGBUG?
-                                        //SERVER thinks midnight UTC is 7am our time on January 1st 2020 
-                                        //TEST thinks midnight UTC is 8am our time on January 1st 2020
                                         //start with the first day of this month
                                         dtAfter = new DateTime(RelativeToday.Year, RelativeToday.Month, 1, RelativeToday.Hour, RelativeToday.Minute, 00);
                                         //Add a Month
@@ -487,8 +469,6 @@ namespace AyaNova.DataList
 
                                         //case 1155
                                         dtAfter = dtAfter.AddSeconds(-1);
-                                        //TODO: REMOVE THIS TESTING
-                                        // log.LogInformation($"NEXT MONTH TOKEN BUILDER IMMEDIATELY BEFORE BUILDING FRAGMENT: BEFORE={dtBefore.ToString()} AND AFTER={dtAfter.ToString()}");
                                         BuildBetweenTwoDatesFragment(SqlColumnNameToFilter, sb, dtAfter, dtBefore);
                                         break;
                                     case DataListFilterSpecialToken.FourteenDayWindow: