diff --git a/.changes/unreleased/Under the Hood-20231107-175844.yaml b/.changes/unreleased/Under the Hood-20231107-175844.yaml
new file mode 100644
index 00000000..ef9d2181
--- /dev/null
+++ b/.changes/unreleased/Under the Hood-20231107-175844.yaml	
@@ -0,0 +1,6 @@
+kind: Under the Hood
+body: made DatePart an ExtendedEnum
+time: 2023-11-07T17:58:44.412914-06:00
+custom:
+  Author: DevonFulcher
+  Issue: None
diff --git a/dbt_semantic_interfaces/type_enums/date_part.py b/dbt_semantic_interfaces/type_enums/date_part.py
index e02e494f..2c269fe6 100644
--- a/dbt_semantic_interfaces/type_enums/date_part.py
+++ b/dbt_semantic_interfaces/type_enums/date_part.py
@@ -1,14 +1,28 @@
-from enum import Enum
 from typing import List
 
-from dbt_semantic_interfaces.enum_extension import assert_values_exhausted
+from dbt_semantic_interfaces.enum_extension import ExtendedEnum, assert_values_exhausted
 from dbt_semantic_interfaces.type_enums.time_granularity import TimeGranularity
 
 
-class DatePart(Enum):
+class DatePart(ExtendedEnum):
     """Date parts able to be extracted from a time dimension.
 
-    Week is not an option due to divergent results across engine contexts see: https://github.com/dbt-labs/metricflow/pull/812
+    Note this does not support WEEK (aka WEEKOFYEAR), because week numbering is very strange.
+    The ISO spec calls for weeks to start on Monday. Fair enough. It also calls for years to
+    start on Monday, but only about 1 out of every 7 do. In order to ensure years start on
+    Monday, the ISO decided that the first day of any given year is the Monday of the week
+    containing the first Thursday of that year. Consequently, the ISO standard produces
+    weeks numbered 1-53, but any days belonging to the preceding calendar year but in the
+    first week of the new year are part of the new ISO year. This is not really what people
+    expect.
+
+    But there's more - different SQL engines also have different implementations of week of year.
+    When not using ISO, you get either 0-53, 1-54, or 1-53 with different ways of deciding
+    how to count the first few days in any given year. As such, we just don't support this.
+
+    When the time comes, we can support week using whatever standard makes the most sense for
+    our usage context, but as it is not clear what that standard looks like we simply don't
+    support date_part = week for now.
 
     TODO: add support for hour, minute, second once those granularities are available
     """