haskell-beam / haskell-beam/beam

now_ or currentTimestamp_ in UTCTime

Open
#823 3 comments 0 reactions 0 assignees View on GitHub
breaking change bug
Dominant language
Haskell
Stars
635
Forks
193
PR merge metrics
No merged PRs in 30d

Description

### Why do `now_` and `currentTimestamp_` use `LocalTime` in Beam?

In PostgreSQL, `now()` and `CURRENT_TIMESTAMP` return a timestamp with time zone.

However, in Beam:

* `now_` from `beam-postgres` has a `LocalTime`-based type.

* `currentTimestamp_` from `beam-core` also produces `LocalTime`.

This becomes problematic when the application’s data model uses `UTCTime`.

For example, I am building a CTE-based statement containing multiple inserts and updates. One insert returns some values that are then used as part of the input to a subsequent insert. For timestamp columns, I want PostgreSQL to generate the value using `now()` or `CURRENT_TIMESTAMP`.

I cannot use `default_` in this particular query shape, so I need to include the timestamp expression explicitly. However, because Beam represents these expressions as `LocalTime`, I cannot use them for a column whose Haskell type is `UTCTime`.

This makes it difficult to construct dynamic, composable insert and update queries while still relying on the database clock.

Why are `now_` and `currentTimestamp_` represented as `LocalTime` rather than `UTCTime` in Beam?

Is there a recommended way to:

1. use PostgreSQL’s `now()` or `CURRENT_TIMESTAMP` for a `UTCTime` column;

2. cast or convert the expression safely inside the Beam query; or

3. we can introduce some new UTCTime compatible functions which can be used to satisfy the types, since these are pure renderings for the sql anyway and have nothing to do in haskell codebase?

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by locating the now_ and currentTimestamp_ entry points in beam-postgres and beam-core, then trace their expression types and PostgreSQL rendering. Compare those definitions with UTCTime column usage and determine whether a cast, conversion, or new UTCTime-compatible function is appropriate. Done means the supported approach is established and covered by relevant tests or documentation.

Written by the indexing model from the issue text.

Assessment

Tech stack
haskell, postgresql
Domain
backend-api-design, databases
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.