implementation of timestamp support

[mgacc0]

Hi Kirill, your package is great 👏

what's the timeframe for implementation of timestamp support?

  tibble(timestamp = now()) %>%
    as_duckdb_tibble()
#> Error in `check_df_for_rel()`:
#> ! Can't convert column `timestamp` to relational.

[krlmlr]

Thanks. This is what happens when I run the code on my machine:

tibble(timestamp = now()) %>%
  as_duckdb_tibble()
#> Error in tibble(timestamp = now()) %>% as_duckdb_tibble(): could not find function "%>%"

^{Created on 2025-05-01 with reprex v2.1.1}

I know where the pipe and tibble() comes from, but I'm not so sure about the now() function. We ask contributors to use the reprex package (as I did) because it makes these kinds of problems obvious and also makes it easy for me to rerun the code and understand the underlying problem.

[mgacc0]

Sorry Kirill. I thought it was evident:
https://lubridate.tidyverse.org/reference/now.html

[krlmlr]

Thanks. I can run it now:

tibble::tibble(timestamp = lubridate::now()) |>
  duckplyr::as_duckdb_tibble()
#> Error in `check_df_for_rel()` at duckplyr/R/relational-duckdb.R:120:3:
#> ! Can't convert column `timestamp` to relational.

^{Created on 2025-05-01 with reprex v2.1.1}

Just curious: why does using the reprex package seem so difficult?

Checking what now() is doing:

dput(lubridate::now())
#> structure(1746129544.63473, class = c("POSIXct", "POSIXt"), tzone = "")

^{Created on 2025-05-01 with reprex v2.1.1}

The following works today:

tibble::tibble(timestamp = lubridate::now(tzone = "UTC")) |>
  duckplyr::as_duckdb_tibble()
#> # A duckplyr data frame: 1 variable
#>   timestamp          
#>   <dttm>             
#> 1 2025-05-01 19:59:54

^{Created on 2025-05-01 with reprex v2.1.1}

If we allow the current time zone (which happens when tzone = "UTC" is omitted), we might get surprising results with functions that extract the date from the timestamp because it's all UTC for DuckDB. How do you feel about that?

[mgacc0]

Sorry. I hadn't realized the problem actually stemmed from that previous DuckDB limitation.
For now (and for me), supporting only UTC timestamps is sufficient.
I've had a similar problem with some other libraries for writing Parquet files: needing to force the conversion to UTC before calling the library.

Do you think it's prudent to expand the error message displayed by duckplyr to inform that "only UTC timestamps can be used"?

[krlmlr]

Good idea!