filesizeformat filter units unclear

[Antti Kaihola]

The filesizeformat filter calculates prefixes in multiplies of 1024. This is ambiguous, since the units "kilobyte", "megabyte" and "gigabyte" are currently commonly used to express both decimal and binary based sizes. For "kilobytes" and "megabytes" the difference is probably unsignificant (1,000 vs. 1,024 and 1,000,000 vs. 1,048,576), but in the case of gigabytes it starts to be substantial.

At least these two solutions are possible:

1. use decimal instead of binary and remind developers in the documentation to mention about it to users if necessary:
   • KB = 1,000 bytes
   • MB = 1,000,000 bytes
   • GB = 1,000,000,000 bytes
2. use IEC prefixes:
   • KiB = 1,024 bytes
   • MiB = 1,0242 bytes
   • GiB = 1,0243 bytes

See also:

• ​http://en.wikipedia.org/wiki/Binary_prefix
• ​http://en.wikipedia.org/wiki/Gigabyte

[Ivan Giuliani]

I'm not worried about being extremely correct here. I think that if you need more precision you can write your own filter, but for the common use the default should be enough. Pushing it to post-1.0 anyway, since it's a feature request.

[Daniel Pope <dan@…>]

The current implementation is wrong but it does have the advantage of being exactly what Windows does; it's therefore sensible for the vast majority of end-users.

On the other hand, Linux apps are getting this right more and more, using both the appropriate unit and prefix. We should provide the tools to allow users to get this right, especially if their site will have a technical focus.

I suggest providing two additional filters, |filesize and |memorysize perhaps, that implement SI and IEC logic and corresponding prefixes respectively, and just noting in the documentation that the older filesizeformat is not strictly correct.

[Florian Sening]

It should display the SI version of the value - anything other is just plain wrong (and shouldn't be used since years). The name filesizeformat is okay for me - but maybe another version of filesizeformat displaying the binary representation would be a great idea.

[Florian Sening]

Fixes filesizeformat so it will display the SI version of the value.

[Florian Sening]

I've added a little patch that fixes the behaviour. It also makes the function more readable.

[Daniel Pope <dan@…>]

@Semmel: The SI version is the decimal scale. IEC is the binary scale.

It's not "plain" wrong to display the binary scale with the decimal units: Windows does this and it's Wikipedia policy too. Wikipedia editors reckoned that it was more important to be understood by the ignorant than to be unambiguous.

However, the correct format for file sizes is the SI scale. Only addressable space should be measured with the IEC scale. You have modified the file size function in exactly the wrong way for formatting file sizes: it is neither correct nor has historical precedent.

[Daniel Pope <dan@…>]

Implementation for all three byte size schemes

[Florian Sening]

Just because Windows does it says nothing because Windows does so much "just plain wrong". ;) But well - i think you and Wikipedia are right. So there should be two versions, one for SI scale and one for IEC scale. I've just checked you patch - i'm not sure yet if filesize and memorysize are fitting names. I'll think about it. So far: Keep up the good work. :)

[Malcolm Tredinnick]

There isn't really a big need to put all this into Django. The current filters are useful enough for rough size displays. If you want something else, it is the work of three minutes to write your own filter or download somebody else's. Whilst I realise there a ambiguities here, that's just the point: these terms are unfortunately ambiguous (and the IEC prefixes have never taken off in the practical world). Having two or three different ways to say the same thing is not going to make things any easier for people programming with Django.

So let's not worry about including this into core.

[Florian Sening]

Hmm. I think you're right. We should leave core just as is.

[(none)]

Milestone post-1.0 deleted