Skip to content

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:

Details
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

@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.

@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.

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 <[email protected]>
Signed-off-by: Alessandro Molina <[email protected]>
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 <[email protected]>
Signed-off-by: Sutou Kouhei <[email protected]>
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