add data type and time zone considerations

website/docs/docs/build/metricflow-time-spine.md

@@ -463,9 +463,20 @@ For example, if you use a custom calendar in your organization, such as a fiscal
 
 - This is useful for calculating metrics based on a custom calendar, such as fiscal quarters or weeks. 
 - Use the `custom_granularities` key to define a non-standard time period for querying data, such as a `retail_month` or `fiscal_week`, instead of standard options like `day`, `month`, or `year`.
-- Ensure the the `standard_granularity_column` is a date time type.
 - This feature provides more control over how time-based metrics are calculated.
 
+<Expandable alt_header="Data types and time zone considerations">
+When working with custom calendars in MetricFlow, it's important to ensure:
+
+- Consistent data types &mdash; Both your dimension column and the time spine column should use the same data type to allow accurate comparisons. Functions like `DATE_TRUNC` don't change the data type of the input in some databases (like Snowflake). Using different data types can lead to mismatches and inaccurate results.
+
+  We recommend using `DATETIME` or `TIMESTAMP` data types for your time dimensions and time spine, as they support all granularities. The `DATE` data type may not support higher granularities like hours or minutes.
+
+- Consistent time zones &mdash; Ensure that all your time-related data uses the same time zone. MetricFlow currently doesn't perform any timezone manipulation and inconsistent time zones can cause unexpected results during aggregations and comparisons.
+
+For example:
+If your time spine column is `TIMESTAMP` type and your dimension column is `DATE` type, comparisons between these columns might not work as intended. To fix this, convert your `DATE` column to `TIMESTAMP`, or make sure both columns are the same data type.
+
 ### Add custom granularities
 
 To add custom granularities, the Semantic Layer supports custom calendar configurations that allow users to query data using non-standard time periods like `fiscal_year` or `retail_month`. You can define these custom granularities (all lowercased) by modifying your model's YAML configuration like this: