Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARROW-16407: [R] Extend parse_date_time to cover hour, dates, and minutes components #13196

Merged
merged 47 commits into from
Jun 29, 2022

Conversation

dragosmg
Copy link
Contributor

@dragosmg dragosmg commented May 19, 2022

This PR improves parse_date_time() by:

  • adding support for orders with the hours, minutes, and seconds components
  • adding support for unseparated strings (ARROW-16446)
  • supporting the exact argument:
    • allows users to pass exact = TRUE in which case the orders are taken as they are (they are considered formats and passed to strptime)
    • exact = FALSE implies formats are derived from orders
  • allowing the truncated argument
    • denotes number of formats that might be missing. For example, passing an order like ymd_HMS and a value of 1 for truncated will attempt parsing with both ymd_HMS and ymd_HM orders
  • erroring when the user passes quiet = FALSE
  • improves the utility function used to generate formats (which are then passed on to strptime) from orders
    • less hard-coding and increased ability to deal with different orders and separators

the ymd HMS orders (and variants) will parse correctly:

library(dplyr, warn.conflicts = FALSE)
library(lubridate, warn.conflicts = FALSE)
library(arrow, warn.conflicts = FALSE)

test_df <- tibble(
  x = c("2011-12-31 12:59:59", "2010-01-01 12:11", "2010-01-01 12", "2010-01-01")
)

test_df %>%
  mutate(
    y = parse_date_time(x, "Ymd HMS", truncated = 3)
  )
#> # A tibble: 4 × 2
#>   x                   y                  
#>   <chr>               <dttm>             
#> 1 2011-12-31 12:59:59 2011-12-31 12:59:59
#> 2 2010-01-01 12:11    2010-01-01 12:11:00
#> 3 2010-01-01 12       2010-01-01 12:00:00
#> 4 2010-01-01          2010-01-01 00:00:00

test_df %>%
  arrow_table() %>% 
  mutate(
    y = parse_date_time(x, "Ymd HMS", truncated = 3)
  ) %>% 
  collect()
#> # A tibble: 4 × 2
#>   x                   y                  
#>   <chr>               <dttm>             
#> 1 2011-12-31 12:59:59 2011-12-31 12:59:59
#> 2 2010-01-01 12:11    2010-01-01 12:11:00
#> 3 2010-01-01 12       2010-01-01 12:00:00
#> 4 2010-01-01          2010-01-01 00:00:00

Created on 2022-05-19 by the reprex package (v2.0.1)

exact = TRUE can also be used:

library(arrow, warn.conflicts = FALSE)
library(lubridate, warn.conflicts = FALSE)
library(dplyr, warn.conflicts = FALSE)

test_df <- tibble(
  x = c("11/23/1998 07:00:00", "6/18/1952 0135", "2/25/1974 0523", "9/07/1985 01", NA)
)

test_df %>%
  mutate(
    parsed_x =
      parse_date_time(
        x,
        c("%m/%d/%Y %I:%M:%S", "%m/%d/%Y %H%M", "%m/%d/%Y %H"),
        exact = TRUE
      )
  )
#> # A tibble: 5 × 2
#>   x                   parsed_x           
#>   <chr>               <dttm>             
#> 1 11/23/1998 07:00:00 1998-11-23 07:00:00
#> 2 6/18/1952 0135      1952-06-18 01:35:00
#> 3 2/25/1974 0523      1974-02-25 05:23:00
#> 4 9/07/1985 01        1985-09-07 01:00:00
#> 5 <NA>                NA

test_df %>%
  arrow_table() %>% 
  mutate(
    parsed_x =
      parse_date_time(
        x,
        c("%m/%d/%Y %I:%M:%S", "%m/%d/%Y %H%M", "%m/%d/%Y %H"),
        exact = TRUE
      )
  ) %>%
  collect()
#> # A tibble: 5 × 2
#>   x                   parsed_x           
#>   <chr>               <dttm>             
#> 1 11/23/1998 07:00:00 1998-11-23 07:00:00
#> 2 6/18/1952 0135      1952-06-18 01:35:00
#> 3 2/25/1974 0523      1974-02-25 05:23:00
#> 4 9/07/1985 01        1985-09-07 01:00:00
#> 5 <NA>                NA

Created on 2022-05-20 by the reprex package (v2.0.1)

@github-actions
Copy link

@dragosmg dragosmg marked this pull request as ready for review May 19, 2022 15:30
@dragosmg dragosmg marked this pull request as draft May 20, 2022 07:29
@dragosmg dragosmg marked this pull request as draft May 20, 2022 07:29
@dragosmg dragosmg marked this pull request as ready for review May 20, 2022 12:01
Copy link
Member

@jonkeane jonkeane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments for you

r/R/dplyr-datetime-helpers.R Show resolved Hide resolved
r/R/dplyr-datetime-helpers.R Show resolved Hide resolved
r/R/dplyr-datetime-helpers.R Outdated Show resolved Hide resolved
r/R/dplyr-datetime-helpers.R Outdated Show resolved Hide resolved
r/R/dplyr-funcs-datetime.R Show resolved Hide resolved
r/tests/testthat/test-dplyr-funcs-datetime.R Outdated Show resolved Hide resolved
r/R/dplyr-datetime-helpers.R Outdated Show resolved Hide resolved
@dragosmg dragosmg requested a review from jonkeane May 23, 2022 13:21
@dragosmg
Copy link
Contributor Author

@jonkeane I think this is ready for another look

Copy link
Member

@jonkeane jonkeane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is moving, still a few functionality rough edges that need work. A few general notes:

  • I'm still struggling a bit following some of the logic. More comments, especially with details about what's in some of the various variables would be helpful to follow what's going on. It's hard to know now what things are lists of expressions versus lists of characters like "Ym" versus lists of characters like "%Y-%m"

  • Should we test build_formats() directly to detect some of the more bespoke | full set of order checks? This would make the tests a lot easier to reason about (what we're testing is more obvious + we wouldn't need to have a whole data frame + date setup in it) Take a look at the other helper functions to see if the same is true for them.

r/R/dplyr-datetime-helpers.R Outdated Show resolved Hide resolved
r/R/dplyr-datetime-helpers.R Outdated Show resolved Hide resolved
r/R/dplyr-funcs-datetime.R Show resolved Hide resolved
r/R/dplyr-datetime-helpers.R Outdated Show resolved Hide resolved
r/R/dplyr-datetime-helpers.R Show resolved Hide resolved
r/R/dplyr-datetime-helpers.R Show resolved Hide resolved
r/R/dplyr-datetime-helpers.R Show resolved Hide resolved
@dragosmg
Copy link
Contributor Author

dragosmg commented May 25, 2022

Edit: I opened ARROW-16653

Given this is a relatively large PR I propose I open a follow-up ticket to go with a fine-tooth comb and check for edge cases, formats , etc. I think we cover the vast majority of use cases, but I'd like to be able to spend some time looking at unit tests, helpers descriptions, error messages, messaging around unsupported orders (there shouldn't be any left) etc.

@dragosmg dragosmg requested a review from jonkeane May 25, 2022 09:51
@dragosmg dragosmg marked this pull request as draft May 26, 2022 14:37
@dragosmg
Copy link
Contributor Author

dragosmg commented Jun 21, 2022

It looks like combining the separator (e.g. "%y-%m-%d") and non-separator formats (e.g. "%y%m%d") into a single vector (my original implementation) is faster than using them separately based on if the data contains a separator or not.

image

Results table
> results
# A tibble: 2 × 13
  expression      min   median `itr/sec` mem_alloc `gc/sec` n_itr  n_gc total_time result   memory     time            gc      
  <bch:expr> <bch:tm> <bch:tm>     <dbl> <bch:byt>    <dbl> <int> <dbl>   <bch:tm> <list>   <list>     <list>          <list>  
1 separate         6s    6.03s     0.165    15.5MB   0.0292    17     3      1.72m <tibble> <Rprofmem> <bench_tm [20]> <tibble>
2 combined      3.36s    3.37s     0.297    15.5MB   0.0330    18     2      1.01m <tibble> <Rprofmem> <bench_tm [20]> <tibble>
Code
library(dplyr)
library(lubridate)
library(ggplot2)
library(hrbrthemes)
load_all()

test_df <- tibble::tibble(
  a = rep(c("20220614", "2022-06-14"), 1e6)
)

results <- bench::mark(
  separate = test_df %>% 
    arrow_table() %>% 
    mutate(b = parse_date_time(a, orders = "ymd")) %>% 
    collect(),
  combined = test_df %>% 
    arrow_table() %>% 
    mutate(b = parse_date_time_combined(a, orders = "ymd")) %>% 
    collect(), 
  min_iterations = 20
)

results

ggplot2::autoplot(results) +
  theme_ipsum_rc(grid = "XxY") +
  labs(title = "Comparison of format parsing",
       subtitle = 
         "separate = formats with or without separator are tried separately\n
combined = formats are combined in a single vector and all are passed to `coalesce()`")
Details

I benchmarked 3 different versions of separate (using different formats for x with and without separator):

  • using gsub modify the format if x does not have a separator, and
  • derive formats_with_sep and formats_without_sep, iterate over the first (with imap()) but pluck the value from the second, if x does not contain a separator.
  • derive formats_with_sep and formats_without_sep, iterate over an independent index with a for loop, and use only the matching format (with or without the separator)

All 3 versions performed similarly, being slower than the version in which the formats were combined into a single vector.

@dragosmg
Copy link
Contributor Author

dragosmg commented Jun 21, 2022

I think this is ready for another look @jonkeane. What changed since our last conversation?

  • I benchmarked my original implementation (formats with and without separators in a single vector) against versions in which the formats were separated (see this comment for more details). The initial implementation proved faster and so I went with that approach.
  • I added roxygen2 headers for the helper functions to give more clarity what is happening where
  • I added a suite of unit tests for build_format_from_order() and build_formats()
  • I rebased.

@dragosmg dragosmg marked this pull request as ready for review June 21, 2022 13:07
Copy link
Member

@paleolimbot paleolimbot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't speak to the completeness of testing/features or motivation since I haven't been following the discussion, but the code itself is easy to read and the approach seems reasonable.

r/R/dplyr-datetime-helpers.R Outdated Show resolved Hide resolved
r/R/dplyr-datetime-helpers.R Outdated Show resolved Hide resolved
r/tests/testthat/test-dplyr-funcs-datetime.R Show resolved Hide resolved
Copy link
Member

@rok rok left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me (but I don't know the R codebase well)!

@rok rok requested a review from nealrichardson June 28, 2022 18:30
@amol- amol- merged commit 10bb618 into apache:master Jun 29, 2022
vibhatha pushed a commit to vibhatha/arrow that referenced this pull request Jul 5, 2022
…inutes components (apache#13196)

This PR improves `parse_date_time()` by:
* adding support for orders with the hours, minutes, and seconds components
* adding support for unseparated strings ([ARROW-16446](https://issues.apache.org/jira/browse/ARROW-16446))
* supporting the `exact` argument:
    * allows users to pass `exact = TRUE` in which case the `orders` are taken as they are (they are considered `formats` and passed to `strptime`)
    * `exact = FALSE` implies `formats` are derived from `orders`
* allowing the `truncated` argument
    * denotes number of formats that might be missing. For example, passing an `order` like `ymd_HMS` and a value of 1 for `truncated` will attempt parsing with both `ymd_HMS` and `ymd_HM` orders  
* erroring when the user passes `quiet = FALSE` 
* improves the utility function used to generate `formats` (which are then passed on to `strptime`) from `orders`
    * less hard-coding and increased ability to deal with different orders and separators 

the `ymd HMS` orders (and variants) will parse correctly:
``` r
library(dplyr, warn.conflicts = FALSE)
library(lubridate, warn.conflicts = FALSE)
library(arrow, warn.conflicts = FALSE)

test_df <- tibble(
  x = c("2011-12-31 12:59:59", "2010-01-01 12:11", "2010-01-01 12", "2010-01-01")
)

test_df %>%
  mutate(
    y = parse_date_time(x, "Ymd HMS", truncated = 3)
  )
#> # A tibble: 4 × 2
#>   x                   y                  
#>   <chr>               <dttm>             
#> 1 2011-12-31 12:59:59 2011-12-31 12:59:59
#> 2 2010-01-01 12:11    2010-01-01 12:11:00
#> 3 2010-01-01 12       2010-01-01 12:00:00
#> 4 2010-01-01          2010-01-01 00:00:00

test_df %>%
  arrow_table() %>% 
  mutate(
    y = parse_date_time(x, "Ymd HMS", truncated = 3)
  ) %>% 
  collect()
#> # A tibble: 4 × 2
#>   x                   y                  
#>   <chr>               <dttm>             
#> 1 2011-12-31 12:59:59 2011-12-31 12:59:59
#> 2 2010-01-01 12:11    2010-01-01 12:11:00
#> 3 2010-01-01 12       2010-01-01 12:00:00
#> 4 2010-01-01          2010-01-01 00:00:00
```

<sup>Created on 2022-05-19 by the [reprex package](https://reprex.tidyverse.org) (v2.0.1)</sup>

`exact = TRUE` can also be used:
<details>

``` r
library(arrow, warn.conflicts = FALSE)
library(lubridate, warn.conflicts = FALSE)
library(dplyr, warn.conflicts = FALSE)

test_df <- tibble(
  x = c("11/23/1998 07:00:00", "6/18/1952 0135", "2/25/1974 0523", "9/07/1985 01", NA)
)

test_df %>%
  mutate(
    parsed_x =
      parse_date_time(
        x,
        c("%m/%d/%Y %I:%M:%S", "%m/%d/%Y %H%M", "%m/%d/%Y %H"),
        exact = TRUE
      )
  )
#> # A tibble: 5 × 2
#>   x                   parsed_x           
#>   <chr>               <dttm>             
#> 1 11/23/1998 07:00:00 1998-11-23 07:00:00
#> 2 6/18/1952 0135      1952-06-18 01:35:00
#> 3 2/25/1974 0523      1974-02-25 05:23:00
#> 4 9/07/1985 01        1985-09-07 01:00:00
#> 5 <NA>                NA

test_df %>%
  arrow_table() %>% 
  mutate(
    parsed_x =
      parse_date_time(
        x,
        c("%m/%d/%Y %I:%M:%S", "%m/%d/%Y %H%M", "%m/%d/%Y %H"),
        exact = TRUE
      )
  ) %>%
  collect()
#> # A tibble: 5 × 2
#>   x                   parsed_x           
#>   <chr>               <dttm>             
#> 1 11/23/1998 07:00:00 1998-11-23 07:00:00
#> 2 6/18/1952 0135      1952-06-18 01:35:00
#> 3 2/25/1974 0523      1974-02-25 05:23:00
#> 4 9/07/1985 01        1985-09-07 01:00:00
#> 5 <NA>                NA
```

<sup>Created on 2022-05-20 by the [reprex package](https://reprex.tidyverse.org) (v2.0.1)</sup>
</details>

Authored-by: Dragoș Moldovan-Grünfeld <dragos.mold@gmail.com>
Signed-off-by: Alessandro Molina <amol@turbogears.org>
kou pushed a commit that referenced this pull request Feb 20, 2023
…Hub issue numbers (#34260)

Rewrite the Jira issue numbers to the GitHub issue numbers, so that the GitHub issue numbers are automatically linked to the issues by pkgdown's auto-linking feature.

Issue numbers have been rewritten based on the following correspondence.
Also, the pkgdown settings have been changed and updated to link to GitHub.

I generated the Changelog page using the `pkgdown::build_news()` function and verified that the links work correctly.

---
ARROW-6338	#5198
ARROW-6364	#5201
ARROW-6323	#5169
ARROW-6278	#5141
ARROW-6360	#5329
ARROW-6533	#5450
ARROW-6348	#5223
ARROW-6337	#5399
ARROW-10850	#9128
ARROW-10624	#9092
ARROW-10386	#8549
ARROW-6994	#23308
ARROW-12774	#10320
ARROW-12670	#10287
ARROW-16828	#13484
ARROW-14989	#13482
ARROW-16977	#13514
ARROW-13404	#10999
ARROW-16887	#13601
ARROW-15906	#13206
ARROW-15280	#13171
ARROW-16144	#13183
ARROW-16511	#13105
ARROW-16085	#13088
ARROW-16715	#13555
ARROW-16268	#13550
ARROW-16700	#13518
ARROW-16807	#13583
ARROW-16871	#13517
ARROW-16415	#13190
ARROW-14821	#12154
ARROW-16439	#13174
ARROW-16394	#13118
ARROW-16516	#13163
ARROW-16395	#13627
ARROW-14848	#12589
ARROW-16407	#13196
ARROW-16653	#13506
ARROW-14575	#13160
ARROW-15271	#13170
ARROW-16703	#13650
ARROW-16444	#13397
ARROW-15016	#13541
ARROW-16776	#13563
ARROW-15622	#13090
ARROW-18131	#14484
ARROW-18305	#14581
ARROW-18285	#14615
* Closes: #33631

Authored-by: SHIMA Tatsuya <ts1s1andn@gmail.com>
Signed-off-by: Sutou Kouhei <kou@clear-code.com>
fatemehp pushed a commit to fatemehp/arrow that referenced this pull request Feb 24, 2023
…to GitHub issue numbers (apache#34260)

Rewrite the Jira issue numbers to the GitHub issue numbers, so that the GitHub issue numbers are automatically linked to the issues by pkgdown's auto-linking feature.

Issue numbers have been rewritten based on the following correspondence.
Also, the pkgdown settings have been changed and updated to link to GitHub.

I generated the Changelog page using the `pkgdown::build_news()` function and verified that the links work correctly.

---
ARROW-6338	apache#5198
ARROW-6364	apache#5201
ARROW-6323	apache#5169
ARROW-6278	apache#5141
ARROW-6360	apache#5329
ARROW-6533	apache#5450
ARROW-6348	apache#5223
ARROW-6337	apache#5399
ARROW-10850	apache#9128
ARROW-10624	apache#9092
ARROW-10386	apache#8549
ARROW-6994	apache#23308
ARROW-12774	apache#10320
ARROW-12670	apache#10287
ARROW-16828	apache#13484
ARROW-14989	apache#13482
ARROW-16977	apache#13514
ARROW-13404	apache#10999
ARROW-16887	apache#13601
ARROW-15906	apache#13206
ARROW-15280	apache#13171
ARROW-16144	apache#13183
ARROW-16511	apache#13105
ARROW-16085	apache#13088
ARROW-16715	apache#13555
ARROW-16268	apache#13550
ARROW-16700	apache#13518
ARROW-16807	apache#13583
ARROW-16871	apache#13517
ARROW-16415	apache#13190
ARROW-14821	apache#12154
ARROW-16439	apache#13174
ARROW-16394	apache#13118
ARROW-16516	apache#13163
ARROW-16395	apache#13627
ARROW-14848	apache#12589
ARROW-16407	apache#13196
ARROW-16653	apache#13506
ARROW-14575	apache#13160
ARROW-15271	apache#13170
ARROW-16703	apache#13650
ARROW-16444	apache#13397
ARROW-15016	apache#13541
ARROW-16776	apache#13563
ARROW-15622	apache#13090
ARROW-18131	apache#14484
ARROW-18305	apache#14581
ARROW-18285	apache#14615
* Closes: apache#33631

Authored-by: SHIMA Tatsuya <ts1s1andn@gmail.com>
Signed-off-by: Sutou Kouhei <kou@clear-code.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants