ayanova/src/api/locale.js

@@ -76,9 +76,9 @@ export default {
     return window.$gz.store.state.userOptions.hour12;
   },
 
-  ///////////////////////////////////////////
-  // Turn a utc date into a vueitfy calendar
-  // schedule control compatible format
+  /////////////////////////////////////////////////////////////////////
+  // Turn a utc ISO date from server into a vuetify calendar
+  // schedule control compatible (epoch) format
   // localized.
   // For ease of use in schedule the epoch (milliseconds) is the best format
   // "It must be a Date, number of seconds since Epoch, or a string in the format of YYYY-MM-DD or YYYY-MM-DD hh:mm. Zero-padding is optional and seconds are ignored.""
@@ -94,12 +94,40 @@ export default {
       return null;
     }
 
-    return new Date(
-      //sv-SE is iso-8601 format so cleanest to parse accurately
-      new Date(value).toLocaleString("sv-SE", {
-        timeZone: timeZoneName
-      })
-    ).getTime();
+    //Not sure what all the parsing was about below, but
+    //if it comes from teh server in iso standard format and ends in '...z' for zulu / utc time
+    //then not sure what the parsing is needed for as this would output the same epoch value as that's independant of anything
+    //I'm thinking I meant to adjust to a new epoch value by offset so need to test this with a forced alternate time zone
+    return new Date(value).getTime();
+
+    // //convert to locale timezone and output in the closest thing to iso-8601 format
+    // let tmp = new Date(value).toLocaleString("sv-SE", {
+    //   timeZone: timeZoneName
+    // });
+    // tmp = tmp.replace(" ", "T");
+    // let ret = new Date(
+    //   tmp
+    //   //sv-SE is iso-8601 format so cleanest to parse accurately
+    //   //bugbug: potential bug here, sv-sE not working on iPad??
+    //   //this always seemed sketchy, how to replace with something
+    //   //less flakey??
+    //   // new Date(value).toLocaleString("sv-SE", {
+    //   //   timeZone: timeZoneName
+    //   // })
+    // ).getTime();
+
+    // window.$gz.store.commit(
+    //   "logItem",
+    //   `utcDateToScheduleCompatibleFormatLocalized:${JSON.stringify({
+    //     value: value,
+    //     timeZoneName: timeZoneName,
+    //     tmp: tmp,
+    //     ret: ret,
+    //     newTest: newtest
+    //   })}`
+    // );
+
+    // return ret;
   },
   ///////////////////////////////////////////////
   // Convert a local schedule epoch timestamp
@@ -294,6 +322,7 @@ export default {
   ///////////////////////////////////////////////
   // Convert a local time only string with date string
   // to UTC and output as ISO 8601
+  //  also converts to time zone specified if diff from browser
   //  (used by time and date picker components)
   //
   localTimeDateStringToUTC8601String(value, timeZoneName) {

ayanova/src/views/home-schedule.vue

@@ -421,6 +421,23 @@
 
 TODO NEXT:
 
+bugbug? If I set new york time zone in ayanova, then in schedule the appointments made previously in vancovuer time zone don't seem to move.  
+  if I make a new appointment in the schedule by dragging like 6pm then open a reminder to fill it, it shows as 9pm
+  so the calendar is still in browser local time, not overridden
+  This works properly when I can make an appointment in sched set to  newyork time at 3pm and then flip to vancovuer time and it's 12:00noon and vice versa
+    it should show in the sched at correct local time and create at correct local time.
+  Notes: date/time pickers don't have time zone settings, so whatever I did there I need to do here
+    For *DISPLAY* need to convert UTC to local iso8601 using locale.utcDateStringToLocal8601DateOnlyString
+    For return back to actual server value it emits using this code:
+     let ret = window.$gz.locale.localTimeDateStringToUTC8601String(
+        theDate + "T" + theTime,
+        vm.timeZoneName
+      );
+
+  So the issue is that the controls will *always* use / expect the time to be local to the browser ignoring the forced conversion
+    so we need to present the UTC time to the control as a local time that works for HERE but in fact is then converted by the difference of the forced time zone when saving
+
+    If I'm in New York and I book for 4pm it should show 1pm to a user in Vancouver zone
  
   TESTING:
     Test here locally and check for layout issues while doing it on all devices 
@@ -920,6 +937,10 @@ export default {
       nativeEvent.stopPropagation();
     },
     async fetchEvents({ start, end }) {
+      window.$gz.store.commit(
+        "logItem",
+        `fetchEvents:${JSON.stringify({ start: start.date, end: end.date })}`
+      );
       // console.log("FetchEvents:", { start: start.date, end: end.date });
       try {
         window.$gz.form.deleteAllErrorBoxErrors(this);
@@ -944,6 +965,10 @@ export default {
           this.formState.serverError = res.error;
           window.$gz.form.setErrorBoxErrors(this);
         } else {
+          // window.$gz.store.commit(
+          //   "logItem",
+          //   `fetchEvents::MAPPING, res.data is: ${JSON.stringify(res.data)}`
+          // );
           this.events = res.data.map(x => {
             return {
               ...x,