From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Simmons To: development@lists.ipfire.org Subject: Re: IPFire standards for unit of speed and date formats Date: Fri, 04 Mar 2022 15:13:01 -0600 Message-ID: In-Reply-To: <515C3523-E508-4EED-92E5-1100EB28134D@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8900291974998575750==" List-Id: --===============8900291974998575750== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 3/3/22 08:05, Michael Tremer wrote: > Hello, > >> On 3 Mar 2022, at 04:18, Jon Murphy wrote: >> >> Hello all, >> >> Maybe the Devs can discuss this during the March 7th, 2022 Monthly Video C= onference meeting? > You are of course welcome to join. It is called Dev Conference because we t= alk 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 f= ormat of dates? =20 >> >> 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=20 >> ------- >> >> 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 poin= t). >> >> 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). =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 (alt= hough 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 b= ytes or kilo bytes. What a nightmare. We should do it as follows: 1 MiB, 17 G= iB, etc. Although nobody will say =E2=80=9Cmebibyte=E2=80=9D, it will be tech= nically correct and what people would expect. I don=E2=80=99t hope that we wi= ll get into this kind of hair splitting, but sooner or later someone will chi= me 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 byte= s, and it would have been nice and short, but that seems to have confused peo= ple 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. =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 sh= ape or the other and it will be confusing if we would have to remember that t= here 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 tech= nical date. Configuration files and so on should use that format, because it = cannot be confused. > > But it isn=E2=80=99t 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 sh= ould 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 =E2=80=9CSince 03/0= 3=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 i= n 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. >> >> >> 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 = general-functions.pl which can be called from virtually anywhere (and will kn= ow 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=E2=80=99t believe this (or something si= milar) is available for Perl. > > Best, > -Michael > >> Thank you! >> Jon >> I'm happy this subject has surfaced.=C2=A0 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).=C2=A0 I enforce HH:MM using a 24 hour clock whenever possible, for the same reasons.=C2=A0 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.=C2=A0 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 --=20 Don=E2=80=99t ever put people in charge of government who don=E2=80=99t belie= ve in government. -- Juli=C3=A1n Castro (February 17,2021) --===============8900291974998575750==--