Remove references to AceTimeTools and AceTimeValidation

Author: bxparks

DEVELOPER.md

@@ -216,7 +216,7 @@ from the client application.)
 
 The AceTime library comes with 3 sets of zoneinfo files, which were
 programmatically generated by the scripts in
-[AceTimeTools](https://github.com/bxparks/AceTimeTools/) from the [IANA TZ
+`AceTimeSuite/compiler/tzcompiler.sh` from the [IANA TZ
 Data](https://www.iana.org/time-zones):
 
 * `src/zonedb/*`

USER_GUIDE.md

@@ -2811,7 +2811,7 @@ C++ code representing these custom zone registries from a list of zones.)
 (**TBD**: It might also be useful for app developers to create custom datasets
 with different range of years. The tools are all here, but not explicitly
 documented currently. Examples of how to this do exist inside the various
-`Makefile` files in the AceTimeValidation project.)
+`Makefile` files under `AceTimeSuite/validation/tests/*/Makefile`.)
 
 <a name="ZoneSorting"></a>
 ## Zone Sorting

src/ace_time/BasicZoneProcessor.h

@@ -170,7 +170,8 @@ inline int8_t compareYearMonth(int16_t aYear, uint8_t aMonth,
  * simplify the implementation of this class. The tzcompiler.py script will
  * remove zones which do not meet these constraints when generating the structs
  * defined by zonedb/zone_infos.h. The constraints are at least the following
- * (see AceTimeTools/transformer.py for the authoratative algorithm):
+ * (see AceTimeSuite/compiler/src/acetimecompiler/transformer/transformer.py for
+ * the authoratative algorithm):
  *
  *  * ZoneInfo UNTIL field must contain only the full year;
  *    cannot contain month, day, or time components
@@ -428,9 +429,9 @@ class BasicZoneProcessorTemplate: public ZoneProcessor {
      * support these zones, if the UTC date is 1/1, then we force the
      * transition cache to be generated using the *previous* year. This
      * workaround will fail for zones which have DST transitions on 1/1.
-     * Therefore, the zone_info.h generator (AceTimeTools/tzcompiler.py) removes
-     * all zones which have time zone transitions on 1/1 from the list of
-     * supported zones.
+     * Therefore, the zone_info.h generator
+     * (AceTimeSuite/compiler/tzcompiler.sh) removes all zones which have time
+     * zone transitions on 1/1 from the list of supported zones.
      *
      * The high level algorithm for determining the DST transitions is as
      * follows:
@@ -701,9 +702,9 @@ class BasicZoneProcessorTemplate: public ZoneProcessor {
       // If a zone needs more transitions than kMaxCacheEntries, the check below
       // will cause the DST transition information to be inaccurate, and it is
       // highly likely that this situation would be caught in the
-      // AceTimeValidation tests. Since these integration tests pass, I feel
-      // confident that those zones which need more than kMaxCacheEntries are
-      // already filtered out by tzcompiler.py.
+      // AceTimeSuite/validation/tests. Since these integration tests pass, I
+      // feel confident that those zones which need more than kMaxCacheEntries
+      // are already filtered out by tzcompiler.py.
       //
       // Ideally, the tzcompiler.py script would explicitly remove those zones
       // which need more than kMaxCacheEntries Transitions. But this would

src/ace_time/ExtendedZoneProcessor.h

@@ -88,8 +88,8 @@ class ExtendedZoneProcessorTemplate: public ZoneProcessor {
      * given in the 'MaxBufSize' comment in the `zone_infos.h` file. Currently
      * that overall maximum is 7, which has been verified by various tests (e.g.
      * HinnantExtendedTest, DateUtilExtendedTest, JavaExtendedTest, and
-     * AcetzExtendedTest) in the AceTimeValidation project. We set this to one
-     * more than 7 for safety.
+     * AcetzExtendedTest) in the AceTimeSuite/validation/tests. We set this to
+     * one more than 7 for safety.
      */
     static const uint8_t kMaxTransitions = 8;
 

src/ace_time/Transition.h

@@ -553,10 +553,11 @@ class TransitionStorageTemplate {
     /**
      * Return the Transition matching the given epochSeconds. Return nullptr if
      * no matching Transition found. If a zone does not have any transition
-     * according to TZ Database, the AceTimeTools/transformer.py script adds an
-     * "anchor" transition at the "beginning of time" which happens to be the
-     * year 1872 (because the year is stored as an int8_t). Therefore, this
-     * method should never return a nullptr for a well-formed ZoneInfo file.
+     * according to TZ Database, the AceTimeSuite/compiler/tzcompiler.sh script
+     * adds an "anchor" transition at the "beginning of time" which happens to
+     * be the year 1872 (because the year is stored as an int8_t). Therefore,
+     * this method should never return a nullptr for a well-formed ZoneInfo
+     * file.
      */
     TransitionForSeconds findTransitionForSeconds(acetime_t epochSeconds)
         const {

src/ace_time/ZoneProcessor.h

@@ -295,7 +295,8 @@ MonthDay calcStartDayOfMonth(int16_t year, uint8_t month,
   * (e.g. "P%T", "E%T"), the time zone deltaMinutes (!= 0 means DST), and the
   * replacement letter (e.g. 'S', 'D', '\0' (represented as '-' in the
   * Rule.LETTER entry). If the Zone.RULES column is '-' or 'hh:mm', then
-  * 'letter' will be set to '\0' also, although AceTimeTools/transformer.py
+  * 'letter' will be set to '\0' also, although
+  * AceTimeSuite/compiler/src/acetimecompiler/transformer/transformer.py
   * should have detected this condition and filtered that zone out.
   *
   * Starting from v2.3, the same algorithm is used by both BasicZoneProcessor

src/ace_time/testing/ValidationDataType.h

@@ -16,8 +16,8 @@ namespace testing {
  * The epochSecond and the expected UTC offset and dateTime components.
  * This is the C++ representation of the 'TestItem' entry in
  * validation_data.json file which is defined in
- * AceTimeTools/datatypes/valtyping.py. The 'type' contains a single
- * character with the following meanings:
+ * AceTimeSuite/compiler/src/acetimecompiler/datatypes/valtyping.py. The 'type'
+ * contains a single character with the following meanings:
  *
  *    * 'A': pre-transition where the UTC offset is different
  *    * 'B': post-transition where the UTC offset is different

src/testingzonedb/zone_infos.h

@@ -143,8 +143,8 @@ const uint32_t kZoneIdUS_Pacific = 0xa950f6ab; // US/Pacific
 
 //---------------------------------------------------------------------------
 // Maximum size of the Transition buffer in ExtendedZoneProcessor for each zone
-// over the given years. Used only in the AceTimeValidation/Extended*Test tests
-// for ExtendedZoneProcessor.
+// over the given years. Used only in the
+// AceTimeSuite/validation/tests/*ExtendedTest tests.
 //
 // MaxBufSize: 6
 //---------------------------------------------------------------------------

src/testingzonedbc/zone_infos.h

@@ -151,8 +151,8 @@ const uint32_t kZoneIdUS_Pacific = 0xa950f6ab; // US/Pacific
 
 //---------------------------------------------------------------------------
 // Maximum size of the Transition buffer in ExtendedZoneProcessor for each zone
-// over the given years. Used only in the AceTimeValidation/Extended*Test tests
-// for ExtendedZoneProcessor.
+// over the given years. Used only in the
+// AceTimeSuite/validation/tests/*ExtendedTest tests.
 //
 // MaxBufSize: 7
 //---------------------------------------------------------------------------

src/testingzonedbx/zone_infos.h

@@ -151,8 +151,8 @@ const uint32_t kZoneIdUS_Pacific = 0xa950f6ab; // US/Pacific
 
 //---------------------------------------------------------------------------
 // Maximum size of the Transition buffer in ExtendedZoneProcessor for each zone
-// over the given years. Used only in the AceTimeValidation/Extended*Test tests
-// for ExtendedZoneProcessor.
+// over the given years. Used only in the
+// AceTimeSuite/validation/tests/*ExtendedTest tests.
 //
 // MaxBufSize: 7
 //---------------------------------------------------------------------------