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

Support binary and decimal bytes (i.e. 1 kibi = 1024 b and 1 kb = 1000 b) #24

merged 28 commits into from Jan 4, 2020


Copy link

@omar omar commented Dec 1, 2016

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 abbreivations KB, MB, etc.
  • BinaryByteSize object: 1 KiB = 1024 B with abbreivations KiB, MiB, etc.

Copy link

Looking forward to when this gets merged

Copy link
Owner Author

omar commented Dec 24, 2018

I decided to make this v2 given the changes that went into. An alpha is up on NuGet

@omar omar mentioned this pull request Jan 6, 2019 Outdated
`ByteSize` assumes `1 kilobyte` = `1024 bytes`. See [why here](
`ByteSize` comes with 3 different ways to represent bytes:

- `DecimalByteSize` which assumes `1 kilobyte` = `1000 bytes` with 2 letter abbrevations `b`, `B`,`KB`, `MB`, `GB`, `TB`, `PB`.

Choose a reason for hiding this comment

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

I've started to use your alpha-version and faced with problem with naming KB for Decimal. It seems that for Decimal it should be 'kB' instead of 'KB'.

Choose a reason for hiding this comment

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

It will be cool if you'll build version new alpha version before completing PR 😎

Copy link

I observed the BinaryByteSize DecimalByteSize NonStandardByteSize thing and I think it is wrong. Let me explain.

Have you ever worked with the DateTime struct? It represents a point in time. And it supports many many string representations that can all be parsed and rendered. There is even a calendar thing that can display a point in time from any calendar. And there are not many structs to work with it; there is just one.

I suggest keeping only one struct that can do all the desired jobs.

  • ToString() and ToStandardString() can be used to display a standard format
  • ToWindowsString() can be used to display the unacceptable but long-loved format (find another name if you wish. I do blame MS for this)
  • ToDecimalString() can be used to display the decimal format
  • ...

There are already some methods like these. FromKibiBytes and FromKiloBytes can be great together in the same class.

If you want compatibility for those who refuse the standard, you can make a static switch that will change the behavior of ToString.

If you don't like having multiple methods to get the string representation, then you can add an enum parameter or a renderer class.

If you still don't like that, you can also create a new format that can be passed to the ToString method (like DateTime). Something like "KiB#3" for "7.012 KiB", "BK" for "7 KB"...

What do you think?

Copy link

Here is how I tend to display sizes in HTML. Everyone can understand whatever the size is.


There is only one size (1179694). There are many way of displaying it. So there should be one struct and many display methods.

Am I wrong?

@omar omar mentioned this pull request Mar 22, 2019
Copy link

Tyrrrz commented Mar 22, 2019

I agree with @sandrock.

Another comparison could be temperature. Temperature is a property of a substance. It can have a value, which is probably represented the most canonically as an average velocity of particles in that substance. But as we all know, the temperature also has many more common representations, i.e. Fahrenheit or Celsius.

The temperature in this context is file size (or "content-length", or, more precisely, "data size"). The base representation is the number of bytes, or just "bytes". Kilobytes, kibibytes, megabytes, mebibytes, etc. are all alternative representations.

It doesn't make much sense to have NonStandardByteSize and StandardByteSize because byte size is always the same, here, on Mars, or anywhere else. Representations, however, can vary.

Copy link
Owner Author

omar commented Mar 24, 2019

I appreciate the feedback in this thread.

To give some context, I initially had a single struct to manage both decimal and binary values. I went down the route of using separate structs make it explicit what the value being represented. I also wanted to keep backwards compatibility and provide users a way to do it the "wrong" way which is what the NonStandardByteSize struct is for. But thinking through this some more and reading the feedback here, I'm not seeing much value in doing it that way.

Given that, I'm thinking of dropping support for the non standard representation and going with the only decimal (kilobyte) and binary (kibibyte) because this is the trend we're heading down based on the limited research I've done.

So to summarize, alpha 2 of this will look like this:

  • Namespace reverted back to ByteSizeLib.
  • ByteSize struct with all the necessary methods to required for binary and decimals (i.e. FromKibiByte and FromKiloByte).
  • No support for representing a kilobyte as 1024 bytes.

Thanks again for taking the time to give your feedback. I'll get started on the changes above. In the meantime, let me know if you agree/disagree with the direction.

# Conflicts:
#	.travis.yml
#	Makefile
#	global.json
#	src/ByteSizeLib.Tests/ByteSizeLib.Tests.csproj
#	src/ByteSizeLib/ByteSizeLib.csproj
Copy link
Owner Author

omar commented Mar 28, 2019

I just pushed alpha 2 to NuGet.

I realized that I don't have a good API setup for the .ToString to output a binary value. That's something I'll take a look at next.

I'm thinking .ToBinaryString() or just make the useBinaryByte parameter available on .ToString().

@omar omar merged commit 1bbc35a into master Jan 4, 2020
@omar omar deleted the metric-byte branch January 4, 2020 01:01
@omar omar changed the title Support metric bytes (i.e. 1 kb = 1000 kb) Support binary and decimal bytes (i.e. 1 kibi = 1024 b and 1 kb = 1000 b) Jan 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

5 participants