#8733 closed (wontfix)
filesizeformat filter units unclear
Reported by: | Antti Kaihola | Owned by: | nobody |
---|---|---|---|
Component: | Template system | Version: | dev |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Design decision needed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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:
- 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
- use IEC prefixes:
- KiB = 1,024 bytes
- MiB = 1,0242 bytes
- GiB = 1,0243 bytes
See also:
Attachments (2)
Change History (12)
comment:1 by , 16 years ago
milestone: | → post-1.0 |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:2 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:3 by , 16 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
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.
comment:4 by , 16 years ago
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.
by , 16 years ago
Attachment: | filesizeformat.patch added |
---|
Fixes filesizeformat so it will display the SI version of the value.
comment:5 by , 16 years ago
I've added a little patch that fixes the behaviour. It also makes the function more readable.
comment:6 by , 16 years ago
@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.
by , 16 years ago
Attachment: | 8733-filesize-formats.diff added |
---|
Implementation for all three byte size schemes
comment:7 by , 16 years ago
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. :)
comment:8 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
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.