Question
Does Streamlit offer a built‑in option to return timezone‑aware datetime values from its date and time widgets?
Rin Nova
0 reputation · 01 Mar 2023, 04:30 UTC
116.7K views
Loading…
0 reputation · 01 Mar 2023, 04:30 UTC
Goal: Ensure that the date and time values returned by Streamlit’s st.date_input and st.time_input widgets can be reliably interpreted in a uniform timezone (e.g., UTC) without requiring each developer to write custom conversion logic.
Constraint: The widgets currently return naive datetime.date and datetime.time objects that reflect the user's browser‑reported local time, with no built‑in tz argument to shift them to a specific zone. This leaves room for inconsistency when the client clock is misconfigured, a VPN alters the perceived offset, or the application runs across multiple regions.
Questions: Should Streamlit add a tz parameter to st.date_input and st.time_input to automatically produce timezone‑aware datetime objects? Would such a change break existing code that expects the current naive return type? How should the library behave when the browser does not provide a trustworthy timezone offset?
As of Streamlit 1.28‑1.35, st.date_input and st.time_input return naive datetime.date and datetime.time objects that reflect the browser’s local time. There is no tz or timezone parameter, and the widgets do not automatically produce timezone‑aware datetime values.
streamlitdatetime.date and datetime.time directly.tz argument for either widget.tz keyword raises a TypeError.import streamlit as st
from datetime import datetime, date, time
from zoneinfo import ZoneInfo # Python 3.9+datetime:d: date = st.date_input('Select date')
t: time = st.time_input('Select time')
naive_dt: datetime = datetime.combine(d, t)aware_dt: datetime = naive_dt.replace(tzinfo=ZoneInfo('UTC'))aware_dt in your logic; ensure all datetimes in the calculation are either all naive or all aware to avoid TypeError.If you are using a Streamlit version newer than 1.35, please confirm the exact version, as a future release could introduce a tz parameter that would change the recommendation.
Use comments to ask for clarification. Post a solution as an answer.
5,250 reputation · 01 Mar 2023, 06:54 UTC
A critical detail when implementing the manual conversion suggested in the previous response is the risk of TypeError during runtime. In Python, mixing naive datetime objects (those without tzinfo) and aware datetime objects in the same operation—such as subtraction or comparison—will cause the application to crash.
If your application logic compares the widget output to a UTC timestamp from a database or API, you must ensure both are aware. For example, if using Python 3.9+, the following pattern prevents these mismatches:
from datetime import datetime, timezone
# Ensure the combined widget value is explicitly aware
aware_dt = naive_dt.replace(tzinfo=timezone.utc)
# Now safe to compare with other aware objects
if aware_dt > datetime.now(timezone.utc):
st.write("Future date selected")Developers should verify their Streamlit version (e.g., 1.35+) and check the tzinfo attribute of the returned object to confirm it remains None before applying these transformations.