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

ByteSize does not follow the IEEE 1541 standard #592

Open
Alexander882 opened this issue Oct 30, 2016 · 15 comments
Open

ByteSize does not follow the IEEE 1541 standard #592

Alexander882 opened this issue Oct 30, 2016 · 15 comments
Labels

Comments

@Alexander882
Copy link

@Alexander882 Alexander882 commented Oct 30, 2016

The ByteSize struct uses values such as kilobyte = 1024 byte, whereas the official IEEE 1541 standard dictates that a kilobyte = 1000 bytes, and kibibyte = 1024 bytes, and so on. Wikipedia Link.

Also, the SI unit kilo- is normally shortened with a lowercase k, not a capital K.

I will happily fix these issues myself, but it might be seen as a bit of a breaking change, so I thought I'd hear your opinion first.

@aloisdg
Copy link
Contributor

@aloisdg aloisdg commented Oct 30, 2016

Hello,

Thank you for pointing this. I think it should be corrected. If it is a breaking change and a good one, we will still add it, just later on.

@Alexander882
Copy link
Author

@Alexander882 Alexander882 commented Oct 30, 2016

Okay, I'll fix it and send in a pull request with my changes then.

I've also realized a few other things about the ByteSize struct, especially the TryParse method:

  • It does not accept negative values.
  • It throws an exception when passed a null- or empty value. The normal TryParse methods (such as long.TryParse) just return false when passed null etc.
@aloisdg
Copy link
Contributor

@aloisdg aloisdg commented Oct 30, 2016

Even better. Please dont forget to add unit tests to show all of this.

@aloisdg aloisdg added the enhancement label Nov 10, 2016
@omar
Copy link

@omar omar commented Nov 25, 2016

Hey guys, I'm the author of ByteSize and peek into this repo every once in a while to see how others use the library and what changes they want.

  • In terms of using IEEE 1541, I agree on that front. When I first created the library I picked what most people are familiar with, even though it's technically wrong. I'm still conflicted about making this change as much as I want. Maybe it would make sense for a v2 release.

  • Negative values: This is an interesting suggestion. I intentionally chose to disallow that behavior thinking it wouldn't be of use. Could you elaborate on a use case for this?

  • TryPrase throwing exceptions: I actually just fixed the TryParse method in v1.2.4.

Thank you for the feedback.

@hangy
Copy link
Contributor

@hangy hangy commented Nov 28, 2016

This is obviously a breaking change, as callers may depend upon the KB values being based on 1024 Bytes instead of 1000 Bytes for whatever calculations. But it could be added as a non-breaking change in a minor release by adding an AppContext feature switch. If the switch is off (default), then 1 KB is 1024 Bytes (current behaviour), and if it's on, then a 1 KB is 1024 Bytes.

Negative values: This is an interesting suggestion. I intentionally chose to disallow that behavior thinking it wouldn't be of use. Could you elaborate on a use case for this?

Negative values could be interesting to display soft disk/mailbox/traffic quota violations.

@omar
Copy link

@omar omar commented Dec 1, 2016

@hangy, thanks for the suggestion. I went ahead and did a quick spike of the metric byte, see these lines and the associated test case.

I opted to use a static field on the actual class because it's more self-documenting than AppContext (which requires magic strings). In addition, AppContext is relatively new and is not supported on older versions of .NET.

In terms of negative values and quota violations, generally those are greater than violations. That is:

var quota = ByteSize.FromMegaBytes(20);
var usage = ByteSize.FromMegaBytes(19);
var newFile = ByteSize.FromMegaBytes(2);

if (usage + newFile > quota) {
    throw new InvalidOperationException($"This file would put you above your quota of { quota }");
}

However, I did just realize that you can't subtract two ByteSize objects. I'm not sure why I didn't include that operation so I can do something like this:

throw new InvalidOperationException($"This file would put you above your quota of { quota } by { usage + newFile - quota }");

I'll add that as well as multiplying and dividing. Lastly, ByteSize does store negative bytes, but it doesn't print them out or parse them, but that can be changed.

I'll add those.

@clairernovotny
Copy link
Member

@clairernovotny clairernovotny commented Apr 18, 2017

@omar @aloisdg @Alexander882 any chance we can get this nailed down in the next week or so for 2.2? Aiming to get 2.2 out in the beginning of May.

@mattdwen
Copy link

@mattdwen mattdwen commented Sep 26, 2017

Hi all, any update on this? I'd like to help out with this one if I can as it's something I'd like to use.

@Alexander882
Copy link
Author

@Alexander882 Alexander882 commented Sep 27, 2017

Sorry for being so slow on this one, I've created a pull request with my implementation

@MehdiK
Copy link
Member

@MehdiK MehdiK commented Nov 3, 2017

This is a significant breaking change, and like @omar mentioned above, while the current terminology is technically wrong, it is what most people are used to and expect.

Can I suggest that we keep the existing functionality as default behavior, to avoid breaking the behavior, and add a strategy to switch to IEEE standard through config? This is an example of a similar implementation.

@omar
Copy link

@omar omar commented Dec 25, 2018

I went ahead and pushed an implementation at omar/ByteSize#24 which can be downloaded from https://www.nuget.org/packages/ByteSize/2.0.0-alpha1

Full design reasoning here https://github.com/omar/ByteSize/blob/db3cacc8314a9f16f327e8ed0df205d3bc186fba/docs/binary-byte.md

Tentative Release Notes

Breaking Changes:

  • Drop support for all platforms except netstandard2.0.
  • Namespace changed to ByteSize from ByteSizeLib.
  • ByteSize renamed to NonStandardByteSize but keeps same functionality.

New Features:

  • DecimalByteSize object: 1 KB = 1000 B with abbreviations KB, MB, etc.
  • BinaryByteSize object: 1 KiB = 1024 B with abbreviations KiB, MiB, etc.

Thoughts?

@sandrock
Copy link

@sandrock sandrock commented Mar 15, 2019

It looks like there exist chaos worshippers. Windows has long been misusing file size units and some guys love it this way. It is not gonna end soon. Now, I think the software industry must make a step and move forward towards non-ambiguous displays of sizes.

It's OK to make a breaking change. Those who will update their library can be notified and apply the changes (and they can also not update).

In 5, 10 or 20 years, will you tolerate that your worldwide-used library does not adhere to a most-needed standard? It's better to do the change now as it may be more difficult in the future.

And... Why not respect the standard from the beginning? An acceptable error that must be fixed ;)

@beeradmoore
Copy link

@beeradmoore beeradmoore commented Dec 18, 2019

Just had an awkward time with this. Using it in a Xamarin.Forms project (iOS/Android) and trying to figure out why my iPhone as being "238 gigabytes" when it really means "238 gibibytes", and then digging around looking why iOS is possibly giving me an incorrect number of device storage size in bytes incorrectly.

Good to know traction from the multiple proposed/implemented solutions is dead in the water.

@omar
Copy link

@omar omar commented Dec 18, 2019

@beeradmoore version 2 of ByteSize supports the proper naming and values, you can get it here https://www.nuget.org/packages/ByteSize/2.0.0-beta1

I plan on release v2 and dropping the beta tag this holiday break. Once that's done, it can be pulled into Humanizer. However, given the large breaking change, I'm not sure how the maintainers want to handle this update.

@omar
Copy link

@omar omar commented Jan 14, 2020

v2 o ByteSize has been released with this feature. See https://www.nuget.org/packages/ByteSize/2.0.0.

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

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.