-
Notifications
You must be signed in to change notification settings - Fork 20
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
Implement EBML date element #128
Conversation
72f60b9
to
c39743d
Compare
Codecov ReportPatch coverage:
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## master #128 +/- ##
==========================================
- Coverage 45.42% 45.40% -0.02%
==========================================
Files 14 14
Lines 2699 2711 +12
==========================================
+ Hits 1226 1231 +5
- Misses 1473 1480 +7
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is surely an improvement, when a 0-sized date is used btw?
Is it possible to create a specific data item to manage zero-sized date? Something like:
I don't know if it's feasible though |
@lu-zero A zero-sized Date Element will fall back to the default value, or the equivalent of 0 if no default exists (which means the date 2001-01-01T00:00:00.000000000 UTC). But Matroska only has one Date Element in the spec currently. And that one has no default value. So at the moment, the only way to sensibly use a zero-sized Date Element in Matroska would be representing the exact date 2001-01-01 at midnight. I think that should be pretty rare. @Luni-4 Sure, that sounds very possible. Should that be included in this PR? |
@FreezyLemon we can add that in a later PR in my opinion |
@FreezyLemon Can we open a new issue for the |
This creates a newtype for EBML dates which is a thin wrapper around an i64 with some special handling for parsing and serialization. Technically, there is an optimization to be done here (see the FIXME), but that should be a pretty rare case.