On 3/3/22 08:05, Michael Tremer wrote:
Hello,
On 3 Mar 2022, at 04:18, Jon Murphy jcmurphy26@gmail.com wrote:
Hello all,
Maybe the Devs can discuss this during the March 7th, 2022 Monthly Video Conference meeting?
You are of course welcome to join. It is called Dev Conference because we talk about development stuff, but everyone can join and at least listen in :)
However, this topic is probably easy enough that we can talk about it here on the list.
Could we create an IPFire standard for units of transfer speed? And for format of dates?
These standards would be used mostly within the WebGUI. And hopefully on the Wiki, Community and all other IPFire entities.
Yes. I would really like this. We have a lot of chaos here, because lots of code was gathered together by lots of different people, and localisation has a heavy influence on things like dates.
Let me say where I would like us to go in the long run. Maybe there should be some smaller steps on the way...
Speed
Ask: Pick Mbps (or maybe Mbit/s) as the official standard for IPFire.
This is a capital `M` for Mega and not a small `m` for milli.
Suggest a maximum of three decimal places (digits to right of decimal point).
Mbps would replace other unit seen like kbit/s, Mbit/s in Traffic In/Out (example Traffic: In 255.70 kbit/s Out 5.49 Mbit/s).
I would vote for GBit/s, MBit/s and kBit/s.
This makes it very clear, that we are talking about bits and not bytes (although this should be known to most people, some people confuse MB/s with Mb/s).
When it comes to file sizes, we have many of places where we show this in bytes or kilo bytes. What a nightmare. We should do it as follows: 1 MiB, 17 GiB, etc. Although nobody will say “mebibyte”, it will be technically correct and what people would expect. I don’t hope that we will get into this kind of hair splitting, but sooner or later someone will chime in and say that “1 MB” isn’t 1,048,576 bytes.
I was a big fan of omitting the unit and just showing the prefix, like “1 M”. Context should make clear, that we are talking about bytes, and it would have been nice and short, but that seems to have confused people in the past.
Date
Ask: Pick a date format of yyyy-mm-dd as the official standard for IPFire.
I've seen dates like mm/dd/yyyy and dd/mm/yyyy.
Yes, there might even be a mix of this. There is no point of having the mm/dd or dd/mm debate. It depends on what you are used to, and there won’t be compromise, because everywhere around us, we will see dates in one shape or the other and it will be confusing if we would have to remember that there is a different format being used in IPFire.
Wherever we need to write a date we should use yyyy-mm-dd when it is a technical date. Configuration files and so on should use that format, because it cannot be confused.
But it isn’t nice to read and very often might waste space, because the year is clear from context.
I would like to write dates like this when we present it to the user: March 3, 2022. That reads well, the month and the day cannot be confused and it should be short. If possible, we can make it even shorter by omitting the year. It is also nicer to use in a sentence instead of writing “Since 03/03”. “Since March 3” works a lot better for my brain.
Time should be clear as HH:MM in 24 hour format. How is that for you guys in the US? I would expect that most Europeans work well with this.
Other Standards
Should data units be reviewed? as MB (Megabytes) and not KiB.
See above.
I can add some images if it helps, but I am guessing it is not needed.
Indeed.
To avoid this chaos, it would be great to have a function for each type in general-functions.pl which can be called from virtually anywhere (and will know the user locale).
Something like: &General::format_date(date);
If we would be using Python, I would suggest using Babel which has a great collection for various locales. I don’t believe this (or something similar) is available for Perl.
Best, -Michael
Thank you! Jon
I'm happy this subject has surfaced. Here's my .02(US$).
Common "formatting/sort functions" for display code are very nice for those desiring alternatives.
I prefer and try to enforce the YYYY-MM-DD date display format on my machines (located in USA), as I am lazy and it's easy to sort (ascending and descending). I enforce HH:MM using a 24 hour clock whenever possible, for the same reasons. Timezone localization is optional, but documented, consistent, and displayed whenever possible.
I prefer multiples of 1024 when measuring bits/bytes, and prefer KiB, MiB, and GiB for quantities of large scale. Network and hardware providers who use multiples of 1000 are "cheaters" and drive me nuts (well, that's my excuse, and I'm sticking to it - my associates may attribute other issues :).
Paul