ayanova/src/api/locale.js

@@ -85,6 +85,12 @@ export default {
   //
   //
   utcDateToScheduleCompatibleFormatLocalized(value, timeZoneName) {
+    //This function takes a UTC iso format date string, parses it into a date then converts that date to the User's configured time zone
+    //outputs that in a format close to ISO, fixes the space in the middle of the output to match ISO 8601 format then returns as an
+    //epoch
+    //this is to support controls that are not time zone settable so they are always in local browser time zone of os, however user may be operating
+    //ayanova in another desired time zone so this is all to support that scenario
+
     if (!value) {
       if (window.$gz.dev) {
         throw new Error(
@@ -94,47 +100,17 @@ export default {
       return null;
     }
 
-    //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
-    // });
-
-    //BUGBUG with original code, apple can't parse the date from here because sv-SE puts a space between date and time and apple can only parse if it has a T between
-    //so force a T and look for other places where this could happen
-
-    // 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;
+    return new Date(
+      new Date(value) //convert to locale timezone and output in the closest thing to iso-8601 format
+        .toLocaleString("sv-SE", {
+          timeZone: timeZoneName
+        })
+        .replace(" ", "T") //Safari can't parse the date from here because sv-SE puts a space between date and time and Safari will only parse if it has a T between
+    ).getTime();
   },
   ///////////////////////////////////////////////
   // Convert a local schedule epoch timestamp
+  // to specified time zone equivalent then
   // to UTC and output as ISO 8601
   //
   //
@@ -143,14 +119,24 @@ export default {
       timeZoneName = this.getResolvedTimeZoneName();
     }
 
-    //parse in the time in the currently used timezone
-    let ret = window.$gz.DateTime.fromMillis(value, {
-      zone: timeZoneName
-    });
+    //input: epoch in local browser time zone
+    //output: transform to date and time string
+    //convert to desired time zone but at same time and date
+    //(i.e. if it browser is vancouver and 1pm is selected but desired is new york's 1pm
+    // so convert the string as if it was new york then back to iso so that the time is adjusted forward
+    // as if the user was in new york in their browser default)
+
+    //parse in the time in to the specified timezone
+    let ret = window.$gz.DateTime.fromISO(
+      //output the sched epoch as local time string without zone
+      new Date(value).toLocaleString("sv-SE").replace(" ", "T"),
+      {
+        zone: timeZoneName
+      }
+    );
 
     ret = ret.setZone("utc"); //convert to UTC
     ret = ret.toISO(); //output as ISO 8601
-
     return ret;
   },
   ///////////////////////////////////////////

ayanova/src/views/home-schedule.vue

@@ -439,9 +439,11 @@ bugbug? If I set new york time zone in ayanova, then in schedule the appointment
 
   FIX FOR BUGS: 
 
+America/New_York
+
   todo: cleaner solution to date morphing would be in locale to break out the bits that do separate things, such as convert to / from time zone, output as iso8601, parse iso8601 etc
     right now every block is doing it's own thing some are using luxon, some are using native js, it's a bit of a mess
-  todo: schedule shows new york time items in vancouver time zone instead so should be 4pm is showing as 1pm
+ 
   todo: schedule is sending appointments when created in schedule and ayanova set to new york time with vancouver time so schedule's 1pm is showing in reminder form as 4pm when it gets there prefilled
   todo: fix apple parsing issue and look for more places where it's happening potentially with sv-SE see locale.utcDateToScheduleCompatibleFormatLocalized for notes and example fix