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

Feature request: Excel date origin #1167

Open
NickCH-K opened this issue Jul 17, 2024 · 2 comments
Open

Feature request: Excel date origin #1167

NickCH-K opened this issue Jul 17, 2024 · 2 comments
Labels
feature a feature request or enhancement

Comments

@NickCH-K
Copy link

lubridate is an extremely good package for handling dates and date conversion. However, it does not accept perhaps one of the most common forms of date data: dates from Excel. Thankfully, many Excel-file-reading functions do this conversion for you, but when they don't it's always one more time Googling to figure out how to convert properly (or, worse, not realizing how oddly Excel handles dates and getting things 70 years off).

The actual task here is very easy, since it just requires setting origin = "1899-12-30". There are many ways this could be implemented, but one simple approach would be, since there is already lubridate::origin, to also have lubridate::excel_origin set to as.POSIXct('1899-12-30').

Maybe this is a bit left-field, but after Googling the correct date for the fiftieth time it occurs to me that this would be a useful convenience function.

@vspinu vspinu added the feature a feature request or enhancement label Dec 4, 2024
@vspinu
Copy link
Member

vspinu commented Dec 5, 2024

but when they don't it's always one more time Googling to figure out how to convert properly (or, worse, not realizing how oddly Excel handles dates and getting things 70 years off).

I don't particularly mind having excel_origin in the package, but the actual use case is not clear to me. How exactly is supposed that value to help and in which circumstances?

@NickCH-K
Copy link
Author

NickCH-K commented Dec 5, 2024

but when they don't it's always one more time Googling to figure out how to convert properly (or, worse, not realizing how oddly Excel handles dates and getting things 70 years off).

I don't particularly mind having excel_origin in the package, but the actual use case is not clear to me. How exactly is supposed that value to help and in which circumstances?

The use case is when you have a data file that, upon import, gives Excel-date-format-integers for numbers (i.e. 45123 or '45123') instead of dates. This sometimes occurs when reading in Excel data directly, or if a file passed through Excel at some point and was exported to another format that did not preserve the date formatting of the date column. I run into this quite frequently when using Excel sheets or CSVs prepared by others or downloaded from the internet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature a feature request or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants