1.8 CMS API kilobit vs kibibit on get api/library

I noticed on the array being return from get api/library that we have 'fileSize' => string '843654' (length=6) and 'fileSizeFormatted' => string '823.88k' (length=7). From the calculations it looks like fileSizeFormatted is returning the file size in kibibits (843654 / 1024). If it was kilobits it should be (843654 / 1000). I was wondering if this is by design? if so then fileSizeFormatted should be designated as “Ki”.

We noticed this when our system and the API did not match up on calculations.
Reference: http://physics.nist.gov/cuu/Units/binary.html

Also most online conversion tools show 843654 bytes converted to kb as 843.654. Unless the site otherwise explains the differences. This could turn out to be a drawn out conversation, but I hope not. I would think that because we are dealing with storage of media one would typically want to know how much space a file is taking up, and therefore one would use the same calculations that the media device storing the media would use. WD and most hard drive manufacturers define a megabyte as 1,000,000 bytes.

Update: Same calculation appears in Media on the CMS

You are right, we use IEC binary prefixes which can either be shown as K or KiB (but never kB) - the fileSize property is the raw byte count, so you could use that against your calculations.

I’ve no objections to providing an option to use SI units instead.