DATE_TRUNC with timezone
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 17.3k
- Forks
- 1.6k
- Avg merge
- 5d 10h
- Merged PRs (30d)
- 28
Description
Is your feature request related to a problem?
I find myself writing to_utc(date_trunc('day', to_timezone(timestamp, 'America/Los_Angeles')), 'America/Los_Angeles') quite often.
Describe the solution you'd like.
It would be great if I could shortcut that into date_trunc('day', timestamp, 'America/Los_Angeles')
This is not unprecedented, dateadd accepts an optional timezone as the final argument, for much the same purpose, so it makes sense to do the same for date_trunc.
Describe alternatives you've considered.
- Keep writing the verbose form
- Write an alternative query language that adds macros/udfs and use that instead
QuestDB UDFs/Macros (#219) would also resolve this, but that is likely a much larger feature.
Full Name:
Soumya S.
Affiliation:
n/a, personal use
Additional context
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the existing date_trunc implementation and its tests, then compare its argument handling with dateadd's optional timezone argument. Confirm the expected behavior for date_trunc('day', timestamp, 'America/Los_Angeles') against the verbose expression in the issue. Done means the new form works with the intended timezone semantics and existing behavior remains covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, sql
- Domain
- backend, databases
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100