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

allow conversion (with loss of precision) for arbitrary precision POSIXct objects #533

Merged
merged 7 commits into from
Jul 18, 2024

Conversation

palday
Copy link
Collaborator

@palday palday commented Jul 17, 2024

closes #396

@palday palday requested a review from ararslan July 17, 2024 17:12
Copy link

codecov bot commented Jul 17, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.22%. Comparing base (1ce81bc) to head (ad6314f).

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #533      +/-   ##
==========================================
+ Coverage   80.15%   80.22%   +0.07%     
==========================================
  Files          26       26              
  Lines        1693     1699       +6     
==========================================
+ Hits         1357     1363       +6     
  Misses        336      336              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

function rcopy(::Type{DateTime}, x::Float64)
ms = ((isnan(x) ? 0 : x) + 62135683200) * 1_000
if !isinteger(ms)
@warn "Precision lost in conversion to DateTime"
Copy link
Member

Choose a reason for hiding this comment

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

Though R users are accustomed to warnings, they're rather unusual for Julia. Perhaps it would make sense for this to be either an error or a @debug message? Any idea what the impact would be of the precision loss in the worst case?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hmmmm.... erroring is in some sense the current behavior, but we could add a more meaningful error message that the user needs to round to millisecond precision first.

R essentially allows for infinite precision here (I couldn't find a documented precision), but Julia restricts this to milliseconds. So you're never more than 1ms off, but whether that matters depends a lot on application domain. Looking at the POSIX roots of this, POSIX mostly cares about seconds, so 🤷.

I think @debug is fine. It's better rounding than what a user would get if they rounded in R, then did the conversion to Julia:

R> x <- as.POSIXct('2020-10-09 12:09:46.1234')

R> round(x, "millisecond")
Error in match.arg(units) : 
  'arg' should be one of “secs”, “mins”, “hours”, “days”, “months”, “years”

Copy link
Member

Choose a reason for hiding this comment

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

Any idea how common it is to have POSIXct values in R with meaningful sub-millisecond precision? At any rate, it could be worth calling this out somewhere in the documentation.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@palday palday requested a review from ararslan July 17, 2024 18:04
if !isinteger(ms)
@debug "Precision lost in conversion to DateTime"
end
ms = round(Int, ms)
Copy link
Member

Choose a reason for hiding this comment

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

Since you're rounding anyway, you could skip the trunc that isinteger does and just check for equality of values pre- and post-round. Doesn't really matter though.

test/convert/datetime.jl Show resolved Hide resolved
@palday palday merged commit caa906f into master Jul 18, 2024
12 of 15 checks passed
@palday palday deleted the pa/microseconds branch July 18, 2024 08:05

!!! note "Conversions to `DateTime` are given in UTC!"
`POSIXct` stores times internally as UTC with a timezone attribute.
The conversion to `DateTime` necessarily strips away timezone information, resulting in UTC values.
Copy link
Member

Choose a reason for hiding this comment

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

If POSIXct has a notion of timezone, I wonder if it should actually be represented on the Julia side as a ZonedDateTime rather than a DateTime. That'd be a breaking change but something possibly worth considering, at least if I understand the situation correctly.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yep, hence #535!

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

Successfully merging this pull request may close these issues.

Dealing with microseconds
2 participants