Add a new TimeUnit for dotnet ticks
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by reviewing the existing TimeUnit options and the TimestampType conversion paths for C# DateTimeOffset. Determine the cross-ecosystem implications of adding a 100-nanosecond tick unit, and define the compatibility and serialization behavior that would constitute a complete proposal.
Written by the indexing model from the issue text.
Description
Describe the enhancement requested
When serializing a DateTimeOffset into an Arrow type, the TimestampType feels like a natural choice. However there is no time unit which fully represents both the precision and range of a C# DateTimeOffset. A DateTimeOffset tick is 100 nanoseconds long and the full range of representable values is between years 0001 and 9999 according to the documentation.
There are currently 2 options for TimeUnit when converting a C# DateTimeOffset to TimestampType
- TimeUnit.Microseconds : Lose precision but be able to fully convert every valid DateTimeOffset to Timestamp
- TimeUnit.Nanoseconds : Keep precision, but the range of representable calendar years is reduced to 1677 - 2262
Of course, users could serialize DateTimeOffset into a long in the Arrow Table and remember the type when deserializing. However, it would be nice to preserve the type information. Having a new TimeUnit equal to a tick would solve this tension.
I appreciate that adding a new time unit would be a fundamental change to arrow across more than just the .NET ecosystem, please let me know if this has been considered before or if the discussion needs to be moved elsewhere.
- Dominant language
- C#
- Stars
- 41
- Forks
- 31
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 15
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/arrow-dotnet
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
apache/arrow-dotnet#410 · 4 comments ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 68/100
apache/arrow-dotnet#446 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
apache/arrow-dotnet#409 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
apache/arrow-dotnet#397 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
apache/arrow-dotnet#378 ·
Maintainers usually reply within 1 day
All issues in apache/arrow-dotnet
Similar issues
-
copilot documentation
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 2 days
-
[Rust][Flaky Test] multiple_deadlines_fire_in_order asserts a wall-clock gap instead of firing orderOpenCI/CD ⚒️ Flaky-tests 🐦
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
valkey-io/valkey-glide#7255 ·
Maintainers usually reply within 3 days
-
bug good first issue
Difficulty 1/5 Under an hour Newbie friendliness 92/100
unoplatform/Uno.Core#99 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
aws/aws-dotnet-ai#75 ·