From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: IPFire standards for unit of speed and date formats Date: Thu, 03 Mar 2022 14:05:11 +0000 Message-ID: <515C3523-E508-4EED-92E5-1100EB28134D@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3688156157225961658==" List-Id: --===============3688156157225961658== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 3 Mar 2022, at 04:18, Jon Murphy wrote: >=20 > Hello all, >=20 > Maybe the Devs can discuss this during the March 7th, 2022 Monthly Video Co= nference meeting? You are of course welcome to join. It is called Dev Conference because we tal= k 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 fo= rmat of dates? =20 >=20 > These standards would be used mostly within the WebGUI. And hopefully on t= he Wiki, Community and all other IPFire entities. Yes. I would really like this. We have a lot of chaos here, because lots of c= ode 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=20 > ------- >=20 > Ask: Pick Mbps (or maybe Mbit/s) as the official standard for IPFire. >=20 > This is a capital `M` for Mega and not a small `m` for milli. >=20 > Suggest a maximum of three decimal places (digits to right of decimal point= ). >=20 > Mbps would replace other unit seen like kbit/s, Mbit/s in Traffic In/Out (e= xample Traffic: In 255.70 kbit/s Out 5.49 Mbit/s). =20 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 (altho= ugh 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 byt= es or kilo bytes. What a nightmare. We should do it as follows: 1 MiB, 17 GiB= , etc. Although nobody will say =E2=80=9Cmebibyte=E2=80=9D, it will be techni= cally correct and what people would expect. I don=E2=80=99t hope that we will= get into this kind of hair splitting, but sooner or later someone will chime= in and say that =E2=80=9C1 MB=E2=80=9D isn=E2=80=99t 1,048,576 bytes. I was a big fan of omitting the unit and just showing the prefix, like =E2=80= =9C1 M=E2=80=9D. 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 > ----- >=20 > Ask: Pick a date format of yyyy-mm-dd as the official standard for IPFire. >=20 > I've seen dates like mm/dd/yyyy and dd/mm/yyyy. =20 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=E2=80=99t= 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 techni= cal date. Configuration files and so on should use that format, because it ca= nnot be confused. But it isn=E2=80=99t nice to read and very often might waste space, because t= he 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 shou= ld be short. If possible, we can make it even shorter by omitting the year. I= t is also nicer to use in a sentence instead of writing =E2=80=9CSince 03/03= =E2=80=9D. =E2=80=9CSince March 3=E2=80=9D 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 =20 > ------------------- > 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. >=20 >=20 > See: https://imgs.xkcd.com/comics/standards.png Indeed. To avoid this chaos, it would be great to have a function for each type in ge= neral-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 co= llection for various locales. I don=E2=80=99t believe this (or something simi= lar) is available for Perl. Best, -Michael > Thank you! > Jon >=20 --===============3688156157225961658==--