You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The two columns "open_at" and "close_at" in the "elections" table (see schema.sql). These columns are set via UPDATE statements (see queries.yaml). The function unixepoch() is used. I don't know what time zone is being used for that.
The epoch seconds are formatted into human-readable times in pages.py:postprocess_election(). That code formats on the server-side regardless of the browser's time zone information. I believe the browser time zone is in the request header (or can be inferred from a date/time in the header), which could then be used to shift the open_at and close_at formatting to the correct time zone.
It is arguable to do the time zone shift and formatting on the client side, but that would seem to require the addition of a new JS library and the associated JS code/complexity to do the formatting (rather than simple EZT template variable insertion on the server's side).
... Okay. I just did a quick search. There is no such request header (primarily: privacy concern). So TZ adjustments must be done in JS on the client. I haven't done this before, so have no recommendations. I'm sure there are libraries that we can grab and place/serve from v3/server/static/js/ ... the server should ensure any time value is passed to the client in UTC.
Activity
tisonkun commentedon Dec 19, 2025
Could you quote/link to the related code block? I may have some time recently to jump into this codebase (again) :D
gstein commentedon Dec 19, 2025
The two columns "open_at" and "close_at" in the "elections" table (see schema.sql). These columns are set via UPDATE statements (see queries.yaml). The function unixepoch() is used. I don't know what time zone is being used for that.
The epoch seconds are formatted into human-readable times in pages.py:postprocess_election(). That code formats on the server-side regardless of the browser's time zone information. I believe the browser time zone is in the request header (or can be inferred from a date/time in the header), which could then be used to shift the open_at and close_at formatting to the correct time zone.
It is arguable to do the time zone shift and formatting on the client side, but that would seem to require the addition of a new JS library and the associated JS code/complexity to do the formatting (rather than simple EZT template variable insertion on the server's side).
... Okay. I just did a quick search. There is no such request header (primarily: privacy concern). So TZ adjustments must be done in JS on the client. I haven't done this before, so have no recommendations. I'm sure there are libraries that we can grab and place/serve from v3/server/static/js/ ... the server should ensure any time value is passed to the client in UTC.