When using export_experiments() with a run_start_time parameter, the function internally calls utc_str_to_millis() to convert the timestamp string to milliseconds for SQL filtering. However, this function returns a float value, which causes issues when:
- The timestamp is used in SQL
WHERE clauses for filtering runs by start_time
- PostgreSQL expects
bigint (integer) values for timestamp columns stored as milliseconds since epoch
- SQL queries fail or produce unexpected results due to float-to-int type mismatch
Current Workaround
We've implemented a monkey patch to fix this issue temporarily:
from mlflow_export_import.common import timestamp_utils
_original_utc_str_to_millis = timestamp_utils.utc_str_to_millis
def _fixed_utc_str_to_millis(sdt):
"""Fixed version that returns int instead of float."""
return int(_original_utc_str_to_millis(sdt))
timestamp_utils.utc_str_to_millis = _fixed_utc_str_to_millis
Expected Behaviour
The utc_str_to_millis() function should return an int representing milliseconds since epoch, not a float.
Environment tested with:
- Package: mlflow-export-import (commit: 46f4d7b)
- Python Version: 3.12
- Database: PostgreSQL (Aurora RDS)
- Context: AWS Lambda function using the package for bulk experiment exports
When using
export_experiments()with arun_start_timeparameter, the function internally callsutc_str_to_millis()to convert the timestamp string to milliseconds for SQL filtering. However, this function returns a float value, which causes issues when:WHEREclauses for filtering runs bystart_timebigint(integer) values for timestamp columns stored as milliseconds since epochCurrent Workaround
We've implemented a monkey patch to fix this issue temporarily:
Expected Behaviour
The
utc_str_to_millis()function should return an int representing milliseconds since epoch, not a float.Environment tested with: