Support international standards (IEC 60027-2 A.2 and ISO/IEC 80000)

[lbeschastny]

It's not important, but it'll be nice to follow international standards of binary prefixes (IEC 60027-2 A.2 and ISO/IEC 80000):

IEC prefix		Representations
Name	Symbol	Base 2	Base 1024
kibi	Ki	210	10241
mebi	Mi	220	10242
gibi	Gi	230	10243
tebi	Ti	240	10244
pebi	Pi	250	10245
exbi	Ei	260	10246
zebi	Zi	270	10247
yobi	Yi	280	10248

References:

• Wikipedia:
  • Binary prefix
• Google unit converter:
  • 1 TiB to TB
  • 1 TiB to B
  • 1 TB to B

[theofidry]

No support for binary (i) has been provided, only byte (B). But any PR to improve that is welcome.

[theofidry]

Actually we could introduce a new entry point for the library, bits(), which follows the same model as bytes. We could then just fix bytes to be actual bytes and bits is simply the current bytes.

That being said that would imply a BC change, what do you think @dougwilson?

[dougwilson]

Hey @theofidry, I'm OK with it not being backward-compatible, as this is not a very complex module and the proposed major is not even very complicated for migration :)

As for thoughts, I'm not sure just yet. I think that supporting the standard is awesome, but at the same time, usually find most people have no idea that "MB" does not mean 1024 KB, especially since the main operating systems display the units incorrectly still.

Ultimately, I think I'd leave it up to you, but those are my 2 cents if you want to think about it :)

[tj]

That's how I felt/feel too, most people pretend that mb == MiB in most scenarios. Maybe some kind of option or alternative method for the standard version?

[theofidry]

Wouldn't a clear (concise) explanation as an introduction in the doc would do?

[theofidry]

Otherwise we could pass a mode parameter in the parser:

var bytes = require('bytes')(mode);

if mode is 'lazy' (default value), the current behaviour would be kept and bits would simply be redundant with bytes. If 'strict' mode is set, 1024 bytes is not longer 1KB but 1KiB.

That being said, there have not been much requests about that so not actually sure of how useful it is... And I personally never bothered with the distinction as well.

[tj]

For me at least the reason behind the module originally was to accept CLI input, which is sort of the lazy-man's version --size 50mb, I've never seen a CLI that accepted --size 50MiB etc. I think for those cases having the default behavior is still useful, even if it's technically incorrect.

[theofidry]

I've never seen a CLI that accepted--size 50MiB`

I've never seen *iB before people brought that up on this repo...

Actually what bother me this feature is I get the feeling that people looking for this are also looking for a converter (from MB to KB or KB to KiB and so on), which this library does not do.

[dougwilson]

It's fine if we want to say that this functionality is outside the scope of this module.

[oneup40]

Actually we could introduce a new entry point for the library, bits(), which follows the same model as bytes. We could then just fix bytes to be actual bytes and bits is simply the current bytes.

This is about binary prefixes vs. metric/SI prefixes (eg: mebibytes vs. megabytes, MiB vs. MB), not bits vs. bytes (eg: megabits vs. megabytes, Mb vs. MB).

1000000 bytes = 1.00 * 1000² = 1.00 megabytes (MB) = 0.954 * 1024² = 0.954 mebibytes (MiB) = 8000000 bits = 8.00 megabits (Mb)

I think that supporting the standard is awesome, but at the same time, usually find most people have no idea that "MB" does not mean 1024 KB, especially since the main operating systems display the units incorrectly still.

Windows is the only major holdout that still reports them incorrectly. iOS / macOS switched in 2009 to correctly use powers of 1000 and use SI prefixes (source). GNU/Linux utilities like ls, du, dd, and truncate take a weird middle ground of using K, M, G instead of KiB, MiB, GiB, but using KB, MB, GB correctly for powers of 1000. Ubuntu has a standard policy for correctly using powers of 1024 with binary prefixes or powers of 1000 with SI prefixes.

Actually what bother me this feature is I get the feeling that people looking for this are also looking for a converter (from MB to KB or KB to KiB and so on), which this library does not do.

I don't think people are looking for a MB/MiB converter as the conversion is pretty easy: value / 1024 * 1000 (or vice versa).

I don't even think people necessarily want it for the parsing side of things. Or at least the number of people who want it for the parsing side is certainly fewer.

People want the output to be correct when using it to convert numeric values to byte unit strings (but at the same time you would probably want to keep both directions consistent, which becomes a sticky issue). The issue is that many other modules are using this module to display number of bytes and every module that uses this one displays them incorrectly without even having the ability to configure it to display them correctly.

[mhelvens]

I don't think people are looking for a MB/MiB converter as the conversion is pretty easy: value / 1024 * 1000 (or vice versa).

Not quite. For KB/KiB you'd be right. But for MB/MiB it's (value / 1024² * 1000²), for GB/GiB it's (value / 1024³ * 1000³), etc.

Anyway, yes. Support for correct units would be welcome.

[gajus]

Someone released a fork with IEC support.

https://www.npmjs.com/package/bytes-iec

[gajus]

More worrying, currently bytes parses "250Mi" as "250", instead of null or an error.

[miraclx]

I wrote a library that supports both schemes, IEC and Decimal bytes.

It has the functionality to parse raw bytes to stringed bytes and stringed bytes to raw bytes
Also, it comes with tons of extra features like relativistic sizing, unit parsing, decimal point parsing, string byte conversion or extraction, etc.

Check it out: https://github.com/miraclx/xbytes

Feel free to debug and file issues, if you find any, let's build something even better.

[KaoruDev]

One use case I would love to support while using Pulumi Kubernetes. GKE Autopilot pods are limited to 10Gi disk space. I mistakenly configured a deployment to have containers with more than 10Gi, but GKE didn't complain about it. I didn't find out until I saw my containers running out of disk space in prod.

This library could help by allowing me to have a check on the Deployment something like:

assert.ok(containers.sum(container => bytes(container.limits["ephemeral-storage"])) < bytes("10Gi"))

[ackle-dev]

I agree that it would be nice if this project used KiB, MiB, etc. I don't think that large changes are necessary: Output just needs to say "MiB" instead of "MB". However, the idea of switching the mode (see quote below) sounds good, with one adjustment: It would be restrictive to declare the mode at import, so maybe the module could export two wrapper functions (supporting MiB and MB respectively) around a central logic function which would be the current one.

Otherwise we could pass a mode parameter in the parser:

var bytes = require('bytes')(mode);

if mode is 'lazy' (default value), the current behaviour would be kept and bits would simply be redundant with bytes. If 'strict' mode is set, 1024 bytes is not longer 1KB but 1KiB.