RE: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
Hi David, > Where would you use it? Why not just drop 12-hour times? > I don't think I've ever formatted a 12-hour time on a computer (unless you > want to count the example quoted below). > Yup, pretty much when we "send" time info to some when it is not life foce-to-face using a 12-hour clock might cause problems. The other party cannot ask us which 10 -o'clock we mean. When I write 22:00 each knows it is 10 in the evening. On the other hand, when we do talk to someone face-to-face we pretty much always use a 12-hour clock because most of the time we use the time as part of a conversation where an event is being discussed and we need to tell when that event is. Having dinner at 6 is pretty much always at 18 and almost never at 06. ;-) > Even accepting that 24:00 Thursday and 00:00 Friday express the same time > could be risky unless you know and trust that the source is consistent. > That's why people like insurance companies often use 23:59 and 00:01, because > to them the exact day matters. Yup, I have seen it go wrong with a band that thought it would be neat to have a concert starting at midnight and got it wrong on their tickets. :-( Someone did not realize 0:00 is just one minute before 0:01 on any given day and 24:00 is just one minute after 23:59 on any given day. Bonno
Re: Default date output format changed after an upgrade to buster
> And the only solution to Zeno's Paradox that I've been able to identify > relies on the notion that space and time are not infinitely > subdivisible. Really? I thought the solution is that while the distance is divided at each step, the time between each step is also divided, so you end up performing an infinite number of step in a finite amount of time. Zeno's paradox has a real-life embodiment which helps think about it: the bouncing ball. It bounces back but with only N% of the original energy, so if you choose N at 50, you get exactly Zeno: at each bounce it bounces half as high, but it also takes half as long to perform that bounce, so while it does bounce an infinite number of times it doesn't bounce for ever. Stefan
Re: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
>> >> It seems intuitively obvious to me that between 11:59 Ante-Meridiem and >> >> 12:01 Post-Meridiem must lie 12:00 Meridiem. (Though 12:00:01 - one >> >> second later - would be Post-Meridiem again.) In my interpretation of this part of the world, it's never exactly noon nor exactly midnight: "12:00" is merely a shorthand to refer to "the interval between 12:00 and 12:01", hence "12:00 AM" is one minute before "12:01 AM" and not one minute after "11:59 AM". But of course it's just a convention and the above is just the reasoning I use to remember the existing convention. Stefan
Re: Default date output format changed after an upgrade to buster
On 2019-09-13 at 12:05, Greg Wooledge wrote: > On Fri, Sep 13, 2019 at 10:44:42AM -0500, David Wright wrote: > >> But time is continuous. > > Maybe. Quantum mechanics still holds some secrets we haven't > learned. And the only solution to Zeno's Paradox that I've been able to identify relies on the notion that space and time are not infinitely subdivisible. I've been considering an alternate one involving the idea that it's just *motion* that isn't infinitely subdivisible, but I'm not sure I've finished working out the kinks of that one to the point where I could comfortably advocate for it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
On 2019-09-13 at 11:50, David Wright wrote: > On Thu 12 Sep 2019 at 23:14:52 (-0400), The Wanderer wrote: > >> On 2019-09-12 at 21:49, David Wright wrote: >>> I don't see a need for a one-letter abbreviation for midnight, nor the >>> wisdom in introducing one that's already used in the same context. >>> Where would you use it? >> >> Wherever you need to specify midnight in a form where specifying any >> other time would get the "AM"/"PM"/"M"(eridiem) abbreviation. >> >> To have a two-letter abbreviation for midnight but a one-letter one for >> noon might be acceptable, although it would feel lopsided to me, but >> just offhand I don't know of any suitable candidate to be that >> two-letter abbreviation. Again, do you have any suggestions? > > No: I'm the one suggesting it's neither desirable nor needed. > So "Wherever you need to" doesn't help. ...this feels like taking me out of context. The question you asked was "Where would you use it?". In response to that, saying just "Wherever you need to" would seem to be short for "Wherever you need to use it", which doesn't even attempt to answer the question. What I actually said, however, is "Wherever you need to specify midnight in a form where [abbreviations would be expected]". That actually has content, albeit not much (because the answer seemed obvious enough to me that I didn't expect the question to need to be asked), and I don't see how your response here acknowledges that. Whether accommodating other people's expectations, by using an abbreviation where they expect one, constitutes "desirable" or "needed" is probably a debatable question. I think this may be one case where I just concede ground to the world's expectations, in the interest of choosing my battles. >>> Why not just drop 12-hour times? I don't think I've ever formatted a >>> 12-hour time on a computer (unless you want to count the example >>> quoted below). >> >> This isn't limited to the context of "on a computer". I think I >> originally came up with the notion of referring to noon as "12:00 M" in >> a context of mentioning the times in out-loud conversation; the >> abbreviations are certainly used in more than just computerized contexts. >> >> For myself, I likely would drop 12-hour time. But as long as the world >> isn't agreeing to do that, pursuing ways to make 12-hour time work more >> logically and less ambiguously is still worthwhile. > > Oh, don't misunderstand me. I'm not arguing against using 12-hour time > in ordinary conversation and in "real life". I've produced scores of > tickets, posters and programmes with 12-hour times, and wouldn't dream > of designing one that advertised a concert at 18:30 rather than 6.30 pm. > I don't design posters with output generated by a date command, but if > that became a necessity through sheer quantity, I would use > date +'%l.%M %P', sure (but I'd add a test for 12). So... I don't think I understand what position you *are* taking, then. >>> No. I think it's more likely that most people don't notice >>> conventions unless they're brought to their attention. Of course, if >>> you're old enough, you had years of pre-digital experience when no >>> one thought of padding dates and times with 0s. That might be why I >>> notice 'odd' formatting like this. >> >> I may be confused. I thought we were talking about why some people / >> tools use zero-padded hours fields with 12-hour time; I don't see how >> the decision to do that could in any way arise from failure to notice a >> convention without having it pointed out. > > I don't think they make a conscious *decision* to use leading zeroes, > they just use the same old %I rather than %_I (≡ %l) because they > hadn't thought about it, and their output didn't jar. > > Conventional: 8 pm9 pm 10 pm 11 pm > Casual:08 pm 09 pm 10 pm 11 pm > > I've omitted the minutes so that the jarring effect might be more obvious. > > When reading fully specified times, with minutes and seconds, I think > an experimental psychologist would be able to show that a leading zero > fools the brain into parsing the time in 24-hour clock mode, and then > the am/pm at the end causes reparsing, which slows comprehension. > Perhaps it wouldn't work like that in America; I don't know. I'd have preferred that myself, but I've actually gotten dinged by this at work. In the approval-request form for applying a proposed change, I specified the implementation time for the change as "07:00" - including the leading zero specifically as a way to indicate that this was 24-hour time - and got the form sent back to me for clarification about whether I meant AM or PM. Purely anecdotal, and at most one data point at that, but it does serve to indicate that the leading zero does not produce that effect in all cases. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the
Re: Default date output format changed after an upgrade to buster
On Fri, Sep 13, 2019 at 10:44:42AM -0500, David Wright wrote: > But time is continuous. Maybe. Quantum mechanics still holds some secrets we haven't learned.
Re: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
On Thu 12 Sep 2019 at 23:14:52 (-0400), The Wanderer wrote: > On 2019-09-12 at 21:49, David Wright wrote: > > On Thu 12 Sep 2019 at 12:42:01 (-0400), The Wanderer wrote: > >> On 2019-09-12 at 12:03, David Wright wrote: > > >>> It might be ambiguous if m were also an abbreviation for midnight, > >>> which I've never come across. > >> > >> Neither have I, but I also haven't come across any *other* abbreviation > >> for it which might be used in this type of context (have you?), and "M" > >> is just as intuitive a choice for abbreviating "midnight" as it is for > >> abbreviating "meridiem". > >> > >> One could argue "M" for "midnight" and "N" for "noon", but then you lose > >> the intuitiveness of M for meridiem, and people would mishear the two as > >> each other in nonline conversation all the time anyway. > > > > I don't see a need for a one-letter abbreviation for midnight, nor the > > wisdom in introducing one that's already used in the same context. > > Where would you use it? > > Wherever you need to specify midnight in a form where specifying any > other time would get the "AM"/"PM"/"M"(eridiem) abbreviation. > > To have a two-letter abbreviation for midnight but a one-letter one for > noon might be acceptable, although it would feel lopsided to me, but > just offhand I don't know of any suitable candidate to be that > two-letter abbreviation. Again, do you have any suggestions? No: I'm the one suggesting it's neither desirable nor needed. So "Wherever you need to" doesn't help. > > Why not just drop 12-hour times? I don't think I've ever formatted a > > 12-hour time on a computer (unless you want to count the example > > quoted below). > > This isn't limited to the context of "on a computer". I think I > originally came up with the notion of referring to noon as "12:00 M" in > a context of mentioning the times in out-loud conversation; the > abbreviations are certainly used in more than just computerized contexts. > > For myself, I likely would drop 12-hour time. But as long as the world > isn't agreeing to do that, pursuing ways to make 12-hour time work more > logically and less ambiguously is still worthwhile. Oh, don't misunderstand me. I'm not arguing against using 12-hour time in ordinary conversation and in "real life". I've produced scores of tickets, posters and programmes with 12-hour times, and wouldn't dream of designing one that advertised a concert at 18:30 rather than 6.30 pm. I don't design posters with output generated by a date command, but if that became a necessity through sheer quantity, I would use date +'%l.%M %P', sure (but I'd add a test for 12). > And of course part of the reason I like the idea is because I find the > odd looks I get when I refer to "12:00 M" without previous explanation > to be amusing. > > >>> When I read emails, I only see the Date: line from the header, and > >>> the timedates used in the quotation lines. One thing I find odd is > >>> mixing AM/PM with hours containing a leading zero. I was always > >>> taught that 7 p.m. or 7pm was not written as 07, but I see that a > >>> lot here. Contrast > >>> > >>> $ TZ=Europe/Paris date +'%I.%M %p' > >>> 06.01 PM > >>> $ TZ=Europe/Paris date +'%l.%M %p' > >>> 6.01 PM > >>> $ > >> > >> That's probably to ease parsing by automated tools, such as sort, so > >> that they don't have to worry about handling field width. > > > > That wouldn't be possible anyway, because you don't have control over, > > for example, whether the time follows the date, and other variability. > > That just makes it even harder; not impossible, but unwieldy and > problematic enough that very few are likely to bother with trying. > > > No. I think it's more likely that most people don't notice > > conventions unless they're brought to their attention. Of course, if > > you're old enough, you had years of pre-digital experience when no > > one thought of padding dates and times with 0s. That might be why I > > notice 'odd' formatting like this. > > I may be confused. I thought we were talking about why some people / > tools use zero-padded hours fields with 12-hour time; I don't see how > the decision to do that could in any way arise from failure to notice a > convention without having it pointed out. I don't think they make a conscious *decision* to use leading zeroes, they just use the same old %I rather than %_I (≡ %l) because they hadn't thought about it, and their output didn't jar. Conventional: 8 pm9 pm 10 pm 11 pm Casual:08 pm 09 pm 10 pm 11 pm I've omitted the minutes so that the jarring effect might be more obvious. When reading fully specified times, with minutes and seconds, I think an experimental psychologist would be able to show that a leading zero fools the brain into parsing the time in 24-hour clock mode, and then the am/pm at the end causes reparsing, which slows comprehension. Perhaps it wouldn't work like that in America; I don't know. Cheers, David.
Re: Default date output format changed after an upgrade to buster
On Thu 12 Sep 2019 at 22:16:45 (-0500), John Hasler wrote: > David Wright writes: > > Odd that they decided to employ that logic in the 21st century after > > (most) clocks had ceased to tick. > > All clocks tick. "Tick" no longer means "emit a noise once per second" > in modern chronometry. The sun doesn't. > > But it is remarkable to use logic to prove a contradiction... > > What contradiction? That meridies could also be either ante meridiem or post meridiem. I thought that was your argument for 'call it noon. Say "12 noon" if you feel like being redundant.'¹ > > ...and infinitesimals... > > No infinitesimals here. Perhaps some limits. Yes, when you're starting from clicks. But time is continuous. > > ...to explain an arbitrary colloquialism. > > Describe, not explain. Most people use it so the rest of us have to > deal with it, like it or not. They are going to assume that you know > what they mean by "12PM". If you don't assign the same meaning to it > that they do you will be late for your meeting. A description needs no logic. The problem, as I see it, is that people invoke logic to explain why *their* choice of am or pm for 12 noon is the "correct" one. A meeting is unlikely to be at 12 midnight unless it's an esbat. But if a *Newfoundlander* invites you for "a lunch at 12", best check what they mean. ¹ 12 noon might be redundant, but if you ever print a poster or suchlike, you realise that when people scan it for the time of the event, their eyes are searching for numbers, not words. So you might write that a meeting is at noon in running text, but the poster needs the digits "12". Cheers, David.
Re: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
The Wanderer writes: >Why do people abbreviate "AM" and "PM" when speaking out loud? They don't know what AM and PM are abbreviations of. They think of AM and PM as words. But I'm referring to abreviations for "noon" and "midnight", which take less time to say than "12 PM" and "12 AM", or even "12 P" and "12 A". -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Default date output format changed after an upgrade to buster
John Hasler wrote: > All clocks tick. "Tick" no longer means "emit a noise once per second" > in modern chronometry. +1 The clock frequency is produced by oscillator at 32.768kHz which means that 15 flops at this frequency produce 1sec. This is one tick.
Re: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
On 2019-09-12 at 23:20, John Hasler wrote: > The Wanderer writes: > >> Wherever you need to specify midnight in a form where specifying any >> other time would get the "AM"/"PM"/"M"(eridiem) abbreviation. > >> To have a two-letter abbreviation for midnight but a one-letter one >> for noon might be acceptable, although it would feel lopsided to me, >> but just offhand I don't know of any suitable candidate to be that >> two-letter abbreviation. Again, do you have any suggestions? > > Why abbreviate at all? It's been a long time since we stopped needing > to save bytes. Why do people abbreviate "AM" and "PM" when speaking out loud? Again, "on a computer" - or even "in writing" - is not the only context where these abbreviations get used. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
The Wanderer writes: > Wherever you need to specify midnight in a form where specifying any > other time would get the "AM"/"PM"/"M"(eridiem) abbreviation. > To have a two-letter abbreviation for midnight but a one-letter one > for noon might be acceptable, although it would feel lopsided to me, > but just offhand I don't know of any suitable candidate to be that > two-letter abbreviation. Again, do you have any suggestions? Why abbreviate at all? It's been a long time since we stopped needing to save bytes. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Default date output format changed after an upgrade to buster
David Wright writes: > Odd that they decided to employ that logic in the 21st century after > (most) clocks had ceased to tick. All clocks tick. "Tick" no longer means "emit a noise once per second" in modern chronometry. > But it is remarkable to use logic to prove a contradiction... What contradiction? > ...and infinitesimals... No infinitesimals here. Perhaps some limits. > ...to explain an arbitrary colloquialism. Describe, not explain. Most people use it so the rest of us have to deal with it, like it or not. They are going to assume that you know what they mean by "12PM". If you don't assign the same meaning to it that they do you will be late for your meeting. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
On 2019-09-12 at 21:49, David Wright wrote: > On Thu 12 Sep 2019 at 12:42:01 (-0400), The Wanderer wrote: > >> On 2019-09-12 at 12:03, David Wright wrote: >>> It might be ambiguous if m were also an abbreviation for midnight, >>> which I've never come across. >> >> Neither have I, but I also haven't come across any *other* abbreviation >> for it which might be used in this type of context (have you?), and "M" >> is just as intuitive a choice for abbreviating "midnight" as it is for >> abbreviating "meridiem". >> >> One could argue "M" for "midnight" and "N" for "noon", but then you lose >> the intuitiveness of M for meridiem, and people would mishear the two as >> each other in nonline conversation all the time anyway. > > I don't see a need for a one-letter abbreviation for midnight, nor the > wisdom in introducing one that's already used in the same context. > Where would you use it? Wherever you need to specify midnight in a form where specifying any other time would get the "AM"/"PM"/"M"(eridiem) abbreviation. To have a two-letter abbreviation for midnight but a one-letter one for noon might be acceptable, although it would feel lopsided to me, but just offhand I don't know of any suitable candidate to be that two-letter abbreviation. Again, do you have any suggestions? > Why not just drop 12-hour times? I don't think I've ever formatted a > 12-hour time on a computer (unless you want to count the example > quoted below). This isn't limited to the context of "on a computer". I think I originally came up with the notion of referring to noon as "12:00 M" in a context of mentioning the times in out-loud conversation; the abbreviations are certainly used in more than just computerized contexts. For myself, I likely would drop 12-hour time. But as long as the world isn't agreeing to do that, pursuing ways to make 12-hour time work more logically and less ambiguously is still worthwhile. And of course part of the reason I like the idea is because I find the odd looks I get when I refer to "12:00 M" without previous explanation to be amusing. >>> When I read emails, I only see the Date: line from the header, and >>> the timedates used in the quotation lines. One thing I find odd is >>> mixing AM/PM with hours containing a leading zero. I was always >>> taught that 7 p.m. or 7pm was not written as 07, but I see that a >>> lot here. Contrast >>> >>> $ TZ=Europe/Paris date +'%I.%M %p' >>> 06.01 PM >>> $ TZ=Europe/Paris date +'%l.%M %p' >>> 6.01 PM >>> $ >> >> That's probably to ease parsing by automated tools, such as sort, so >> that they don't have to worry about handling field width. > > That wouldn't be possible anyway, because you don't have control over, > for example, whether the time follows the date, and other variability. That just makes it even harder; not impossible, but unwieldy and problematic enough that very few are likely to bother with trying. > No. I think it's more likely that most people don't notice > conventions unless they're brought to their attention. Of course, if > you're old enough, you had years of pre-digital experience when no > one thought of padding dates and times with 0s. That might be why I > notice 'odd' formatting like this. I may be confused. I thought we were talking about why some people / tools use zero-padded hours fields with 12-hour time; I don't see how the decision to do that could in any way arise from failure to notice a convention without having it pointed out. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Default date output format changed after an upgrade to buster
On Thu 12 Sep 2019 at 14:13:19 (-0500), John Hasler wrote: > rhkramer writes: > > If 12:01 pm is two minutes after 11:59 am, then 12:00 is AM. > > AM means "before the meridian", that is, before the Sun crosses the > meridian[1]. PM means after the meridian. Time is the ordering of > events. The Sun crossing the meridian is an event which we call noon: > everything else happens either before or after it[2]. 12:00 is noon > (except when it's midnight[3]) so it makes no sense to call it either AM > or PM: call it noon. Say "12 noon" if you feel like being redundant. > > It makes no sense to speak of something happening at noon: only noon > itself happens then[2]. People are going to do so anyway, though, so one > must assume that when they say "The event will occur at noon" they mean > that it will occur during the interval between noon and the first clock > tick after noon. This makes "12:00 noon" 12:00PM. Thus colloquially > 12:00PM is in the middle of the day. Odd that they decided to employ that logic in the 21st century after (most) clocks had ceased to tick. But it is remarkable to use logic to prove a contradiction, and infinitesimals to explain an arbitrary colloquialism. > [1] Notionally. The ancients used local solar time. > > [2] This applies to any tick of your clock. > > [3] Same argument applies to midnight (it's when the Sun crosses the > other meridian), making it 12:00AM. Cheers, David.
Re: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
On Thu 12 Sep 2019 at 12:42:01 (-0400), The Wanderer wrote: > On 2019-09-12 at 12:03, David Wright wrote: > > On Thu 12 Sep 2019 at 09:42:03 (-0400), The Wanderer wrote: > >> On 2019-09-12 at 06:30, Dan Ritter wrote: > > >>> There is only one sensible interpretation: > >>> > >>> If 11:59 AM is two minutes before 12:01 PM, then 12:00 is PM. > >>> > >>> If 11:59 PM is two minutes before 12:01 AM, then 12:00 is AM. > >> > >> I take a slightly different approach, based on the apparent actual > >> meanings of the words for which "AM" and "PM are abbreviations. > >> > >> It seems intuitively obvious to me that between 11:59 Ante-Meridiem and > >> 12:01 Post-Meridiem must lie 12:00 Meridiem. (Though 12:00:01 - one > >> second later - would be Post-Meridiem again.) > >> > >> Similarly, though less an "obvious necessity" consequence, between 11:59 > >> Post-Meridiem and 12:01 Ante-Meridiem lies 12:00 Midnight. (I understand > >> "meridiem" to be derived from a word which would have literally meant > >> "mid-day".) > > > > Meridies (nominative case in Latin). > > > >> Both are intuitively represented as "12:00 M" - with no "A" or "P" - and > >> that, in its turn, is ambiguous. > > > > It might be ambiguous if m were also an abbreviation for midnight, > > which I've never come across. > > Neither have I, but I also haven't come across any *other* abbreviation > for it which might be used in this type of context (have you?), and "M" > is just as intuitive a choice for abbreviating "midnight" as it is for > abbreviating "meridiem". > > One could argue "M" for "midnight" and "N" for "noon", but then you lose > the intuitiveness of M for meridiem, and people would mishear the two as > each other in nonline conversation all the time anyway. I don't see a need for a one-letter abbreviation for midnight, nor the wisdom in introducing one that's already used in the same context. Where would you use it? Why not just drop 12-hour times? I don't think I've ever formatted a 12-hour time on a computer (unless you want to count the example quoted below). Even accepting that 24:00 Thursday and 00:00 Friday express the same time could be risky unless you know and trust that the source is consistent. That's why people like insurance companies often use 23:59 and 00:01, because to them the exact day matters. > >> That being part of why I stick with 24-hour time whenever possible. > > > > When I read emails, I only see the Date: line from the header, and > > the timedates used in the quotation lines. One thing I find odd is > > mixing AM/PM with hours containing a leading zero. I was always > > taught that 7 p.m. or 7pm was not written as 07, but I see that a > > lot here. Contrast > > > > $ TZ=Europe/Paris date +'%I.%M %p' > > 06.01 PM > > $ TZ=Europe/Paris date +'%l.%M %p' > > 6.01 PM > > $ > > That's probably to ease parsing by automated tools, such as sort, so > that they don't have to worry about handling field width. That wouldn't be possible anyway, because you don't have control over, for example, whether the time follows the date, and other variability. No. I think it's more likely that most people don't notice conventions unless they're brought to their attention. Of course, if you're old enough, you had years of pre-digital experience when no one thought of padding dates and times with 0s. That might be why I notice 'odd' formatting like this. Cheers, David.
Re: Default date output format changed after an upgrade to buster
rhkramer writes: > If 12:01 pm is two minutes after 11:59 am, then 12:00 is AM. AM means "before the meridian", that is, before the Sun crosses the meridian[1]. PM means after the meridian. Time is the ordering of events. The Sun crossing the meridian is an event which we call noon: everything else happens either before or after it[2]. 12:00 is noon (except when it's midnight[3]) so it makes no sense to call it either AM or PM: call it noon. Say "12 noon" if you feel like being redundant. It makes no sense to speak of something happening at noon: only noon itself happens then[2]. People are going to do so anyway, though, so one must assume that when they say "The event will occur at noon" they mean that it will occur during the interval between noon and the first clock tick after noon. This makes "12:00 noon" 12:00PM. Thus colloquially 12:00PM is in the middle of the day. [1] Notionally. The ancients used local solar time. [2] This applies to any tick of your clock. [3] Same argument applies to midnight (it's when the Sun crosses the other meridian), making it 12:00AM. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
On 2019-09-12 at 12:03, David Wright wrote: > On Thu 12 Sep 2019 at 09:42:03 (-0400), The Wanderer wrote: > >> On 2019-09-12 at 06:30, Dan Ritter wrote: >>> There is only one sensible interpretation: >>> >>> If 11:59 AM is two minutes before 12:01 PM, then 12:00 is PM. >>> >>> If 11:59 PM is two minutes before 12:01 AM, then 12:00 is AM. >> >> I take a slightly different approach, based on the apparent actual >> meanings of the words for which "AM" and "PM are abbreviations. >> >> It seems intuitively obvious to me that between 11:59 Ante-Meridiem and >> 12:01 Post-Meridiem must lie 12:00 Meridiem. (Though 12:00:01 - one >> second later - would be Post-Meridiem again.) >> >> Similarly, though less an "obvious necessity" consequence, between 11:59 >> Post-Meridiem and 12:01 Ante-Meridiem lies 12:00 Midnight. (I understand >> "meridiem" to be derived from a word which would have literally meant >> "mid-day".) > > Meridies (nominative case in Latin). > >> Both are intuitively represented as "12:00 M" - with no "A" or "P" - and >> that, in its turn, is ambiguous. > > It might be ambiguous if m were also an abbreviation for midnight, > which I've never come across. Neither have I, but I also haven't come across any *other* abbreviation for it which might be used in this type of context (have you?), and "M" is just as intuitive a choice for abbreviating "midnight" as it is for abbreviating "meridiem". One could argue "M" for "midnight" and "N" for "noon", but then you lose the intuitiveness of M for meridiem, and people would mishear the two as each other in nonline conversation all the time anyway. >> That being part of why I stick with 24-hour time whenever possible. > > When I read emails, I only see the Date: line from the header, and > the timedates used in the quotation lines. One thing I find odd is > mixing AM/PM with hours containing a leading zero. I was always > taught that 7 p.m. or 7pm was not written as 07, but I see that a > lot here. Contrast > > $ TZ=Europe/Paris date +'%I.%M %p' > 06.01 PM > $ TZ=Europe/Paris date +'%l.%M %p' > 6.01 PM > $ That's probably to ease parsing by automated tools, such as sort, so that they don't have to worry about handling field width. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Default date output format changed after an upgrade to buster
On Thursday, September 12, 2019 08:26:23 AM Nate Bargmann wrote: > Not all Walmarts are like that. ;-) > > The one in Beatrice, NE is as you describe, at least the north most > entrance. The ones in Marysviile, KS and Fairbury, NE are "normal", > i.e. ingress on the right when outside the store and egress on the right > when inside the store. Well, I'm glad some Walmarts are true "red blooded" Americans ;-) > Apologies for more clock drift. ;-D Yeah, me too!
Re: Default date output format changed after an upgrade to buster
On Thursday, September 12, 2019 08:09:18 AM Michael Stone wrote: > The railroads solved this more than a century ago: you just never use > 12:00 and stick with 11:59 or 12:01. Sometimes communicating clearly is > more important than being right. I like that (but getting everyone to adhere to that ...
Re: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
On Thu 12 Sep 2019 at 09:42:03 (-0400), The Wanderer wrote: > On 2019-09-12 at 06:30, Dan Ritter wrote: > > David Wright wrote: > >> > >> What surprised me is the use of 12am and 12pm in the States. When I > >> was at grammar school (in the days of 12hour times), you lost marks > >> for writing either of these contradictions. It was either 12 noon, > >> 12 midnight, or 12 o'clock (where there's no ambiguity). > > > > 12 o'clock is the only one of those which is ambiguous. > > > >> Even more astonishing is the fact that the US Government switched > >> their am/pm meanings sometime between 2000 and 2008, which shows > >> just how ambiguous they are. > > > > There is only one sensible interpretation: > > > > If 11:59 AM is two minutes before 12:01 PM, then 12:00 is PM. > > > > If 11:59 PM is two minutes before 12:01 AM, then 12:00 is AM. > > I take a slightly different approach, based on the apparent actual > meanings of the words for which "AM" and "PM are abbreviations. > > It seems intuitively obvious to me that between 11:59 Ante-Meridiem and > 12:01 Post-Meridiem must lie 12:00 Meridiem. (Though 12:00:01 - one > second later - would be Post-Meridiem again.) > > Similarly, though less an "obvious necessity" consequence, between 11:59 > Post-Meridiem and 12:01 Ante-Meridiem lies 12:00 Midnight. (I understand > "meridiem" to be derived from a word which would have literally meant > "mid-day".) Meridies (nominative case in Latin). > Both are intuitively represented as "12:00 M" - with no "A" or "P" - and > that, in its turn, is ambiguous. It might be ambiguous if m were also an abbreviation for midnight, which I've never come across. One can understand why, in the days of 12-hour clocks, midday was something distinctive, whereas the precise time of midnight (as contrasted with "the middle of the night") was largely irrelevant. Many of the times we use were originally derived from counting the hours after dawn: logical to the way people lived their lives. So people took their siesta at the sixth hour and monks prayed in nones at the ninth, mid-afternoon (ironically: noon, like the start of the new year, has since drifted). > That being part of why I stick with 24-hour time whenever possible. When I read emails, I only see the Date: line from the header, and the timedates used in the quotation lines. One thing I find odd is mixing AM/PM with hours containing a leading zero. I was always taught that 7 p.m. or 7pm was not written as 07, but I see that a lot here. Contrast $ TZ=Europe/Paris date +'%I.%M %p' 06.01 PM $ TZ=Europe/Paris date +'%l.%M %p' 6.01 PM $ > > The problem stems from 12 actually indicating what anybody sensible > > would consider 0. > > As is likely part of the reason why the usual 24-hour clock goes from > 23:59 to 00:00, yes. Not forgetting 23:59:60 on occasions. Cheers, David.
Re: Default date output format changed after an upgrade to buster
On Thu 12 Sep 2019 at 13:48:07 (-), Curt wrote: > On 2019-09-12, Greg Wooledge wrote: > > On Wed, Sep 11, 2019 at 07:31:13PM -0500, David Wright wrote: > >> Even more astonishing is the fact that the US Government switched > >> their am/pm meanings sometime between 2000 and 2008, which shows > >> just how ambiguous they are. > > > > [citation needed] > > https://en.wikipedia.org/wiki/12-hour_clock#cite_note-26 > > The style manual of the United States Government Printing Office used 12 a.m. > for noon and 12 p.m. for midnight until its 2008 edition, when it reversed > these designations,[14][15] later maintained in its 2016 revision.[23] https://www.govinfo.gov/collection/gpo-style-manual?path=/GPO/U.S.%20Government%20Publishing%20Office%20Style%20Manual During the 20th century, they used 12 m. for noon apparently (meridies). I notice that the section heading confuses meridiem with meridian: "9.54. References to meridian in statements of time are abbre- viated as follows:" Cheers, David.
Re: Default date output format changed after an upgrade to buster
On Thu, Sep 12, 2019 at 01:48:07PM -, Curt wrote: > On 2019-09-12, Greg Wooledge wrote: > > On Wed, Sep 11, 2019 at 07:31:13PM -0500, David Wright wrote: > >> Even more astonishing is the fact that the US Government switched > >> their am/pm meanings sometime between 2000 and 2008, which shows > >> just how ambiguous they are. > > > > [citation needed] > > https://en.wikipedia.org/wiki/12-hour_clock#cite_note-26 > > The style manual of the United States Government Printing Office used 12 a.m. > for noon and 12 p.m. for midnight until its 2008 edition, when it reversed > these designations,[14][15] later maintained in its 2016 revision.[23] Interesting, thank you. I guess I should not be surprised that my government had it *wrong* for 148 years.
Re: Default date output format changed after an upgrade to buster
On 2019-09-12, Greg Wooledge wrote: > On Wed, Sep 11, 2019 at 07:31:13PM -0500, David Wright wrote: >> Even more astonishing is the fact that the US Government switched >> their am/pm meanings sometime between 2000 and 2008, which shows >> just how ambiguous they are. > > [citation needed] > > https://en.wikipedia.org/wiki/12-hour_clock#cite_note-26 The style manual of the United States Government Printing Office used 12 a.m. for noon and 12 p.m. for midnight until its 2008 edition, when it reversed these designations,[14][15] later maintained in its 2016 revision.[23] -- Thug: This is a stickup! Now come on. Your money or your life. [long pause] Thug: [repeating] Look, bud, I said, 'Your money or your life.' Jack Benny: I'm thinking, I'm thinking!
Re: 24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
On Thu, Sep 12, 2019 at 09:42:03AM -0400, The Wanderer wrote: I take a slightly different approach, based on the apparent actual meanings of the words for which "AM" and "PM are abbreviations. It seems intuitively obvious to me that between 11:59 Ante-Meridiem and 12:01 Post-Meridiem must lie 12:00 Meridiem. (Though 12:00:01 - one second later - would be Post-Meridiem again.) Similarly, though less an "obvious necessity" consequence, between 11:59 Post-Meridiem and 12:01 Ante-Meridiem lies 12:00 Midnight. (I understand "meridiem" to be derived from a word which would have literally meant "mid-day".) Historically one would simply say "12 noon" or "12 midnight". The entire am/pm controversy is caused by trying to cram the time into limited displays.
24-hour vs. 12-hour time, ambiguity, and abbreviations (was Re: Default date output format changed after an upgrade to buster)
On 2019-09-12 at 06:30, Dan Ritter wrote: > David Wright wrote: >> >> What surprised me is the use of 12am and 12pm in the States. When I >> was at grammar school (in the days of 12hour times), you lost marks >> for writing either of these contradictions. It was either 12 noon, >> 12 midnight, or 12 o'clock (where there's no ambiguity). > > 12 o'clock is the only one of those which is ambiguous. > >> Even more astonishing is the fact that the US Government switched >> their am/pm meanings sometime between 2000 and 2008, which shows >> just how ambiguous they are. > > There is only one sensible interpretation: > > If 11:59 AM is two minutes before 12:01 PM, then 12:00 is PM. > > If 11:59 PM is two minutes before 12:01 AM, then 12:00 is AM. I take a slightly different approach, based on the apparent actual meanings of the words for which "AM" and "PM are abbreviations. It seems intuitively obvious to me that between 11:59 Ante-Meridiem and 12:01 Post-Meridiem must lie 12:00 Meridiem. (Though 12:00:01 - one second later - would be Post-Meridiem again.) Similarly, though less an "obvious necessity" consequence, between 11:59 Post-Meridiem and 12:01 Ante-Meridiem lies 12:00 Midnight. (I understand "meridiem" to be derived from a word which would have literally meant "mid-day".) Both are intuitively represented as "12:00 M" - with no "A" or "P" - and that, in its turn, is ambiguous. That being part of why I stick with 24-hour time whenever possible. > The problem stems from 12 actually indicating what anybody sensible > would consider 0. As is likely part of the reason why the usual 24-hour clock goes from 23:59 to 00:00, yes. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Default date output format changed after an upgrade to buster
On Thu 12 Sep 2019 at 06:30:21 (-0400), Dan Ritter wrote: > David Wright wrote: > > > > What surprised me is the use of 12am and 12pm in the States. When > > I was at grammar school (in the days of 12hour times), you lost > > marks for writing either of these contradictions. It was either > > 12 noon, 12 midnight, or 12 o'clock (where there's no ambiguity). > > 12 o'clock is the only one of those which is ambiguous. Perhaps, for some, I have to rewrite the last sentence so they can understand it. It was either 12 noon or 12 midnight. However, it would have been permissible to write 12 o'clock where there was no ambiguity, as in "Lunch is at 12 o'clock". > > Even more astonishing is the fact that the US Government switched > > their am/pm meanings sometime between 2000 and 2008, which shows > > just how ambiguous they are. > > There is only one sensible interpretation: > > If 11:59 AM is two minutes before 12:01 PM, then 12:00 is PM. > > If 11:59 PM is two minutes before 12:01 AM, then 12:00 is AM. > > The problem stems from 12 actually indicating what anybody > sensible would consider 0. I'm not sure why you think that 0 has any relevance to the 12-hour clock: glancing up, I see no "0" inscribed anywhere (except as the second digit of "10"). Your argument above is arbitrary, placing 12:00 at the *start* of the period of time 12:00, 12:01, 12:02 … The counterargument can be held by anybody actually looking at the face of a clock, where 12 is at the *end* of the sequence … 10, 11, 12. You might see some logic in either, but I can see no logic in maintaining what is a contradiction in terms. So it's just a convention, and one that the US Government changed its view on some years ago. Cheers, David.
Re: Default date output format changed after an upgrade to buster
On Wed, Sep 11, 2019 at 07:31:13PM -0500, David Wright wrote: > Even more astonishing is the fact that the US Government switched > their am/pm meanings sometime between 2000 and 2008, which shows > just how ambiguous they are. [citation needed]
Re: Default date output format changed after an upgrade to buster
* On 2019 12 Sep 06:16 -0500, rhkra...@gmail.com wrote: > Now I consider establishments like Walgreens, Rite-Aid, Walmart, and others > to > be foreign infiltrators, as, when they have an In and an Out door side by > side, > the In is on the left. (Ok, Walmart is only a halfway foreign infiltrator, > as > they typically have at least two entrances with In and Out doors, one of them > has the In door on the left, the other has the In door on the right.) Not all Walmarts are like that. ;-) The one in Beatrice, NE is as you describe, at least the north most entrance. The ones in Marysviile, KS and Fairbury, NE are "normal", i.e. ingress on the right when outside the store and egress on the right when inside the store. Apologies for more clock drift. ;-D - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Default date output format changed after an upgrade to buster
On Thu, Sep 12, 2019 at 06:30:21AM -0400, Dan Ritter wrote: David Wright wrote: What surprised me is the use of 12am and 12pm in the States. When I was at grammar school (in the days of 12hour times), you lost marks for writing either of these contradictions. It was either 12 noon, 12 midnight, or 12 o'clock (where there's no ambiguity). 12 o'clock is the only one of those which is ambiguous. Even more astonishing is the fact that the US Government switched their am/pm meanings sometime between 2000 and 2008, which shows just how ambiguous they are. There is only one sensible interpretation: If 11:59 AM is two minutes before 12:01 PM, then 12:00 is PM. If 11:59 PM is two minutes before 12:01 AM, then 12:00 is AM. The problem stems from 12 actually indicating what anybody sensible would consider 0. The railroads solved this more than a century ago: you just never use 12:00 and stick with 11:59 or 12:01. Sometimes communicating clearly is more important than being right.
Re: Default date output format changed after an upgrade to buster
On 2019-09-12, rhkra...@gmail.com wrote: > > But, ok, I'll try to burn that into my memory -- at night (when it is dark) > 12:00 (midnight) is the beginning of morning (12:00 am). During the day, > when > it is light 12:00 (noon) is the beginning of night (12:00 pm). > >> If 11:59 PM is two minutes before 12:01 AM, then 12:00 is AM. >> >> The problem stems from 12 actually indicating what anybody sensible >> would consider 0. >> There is a special-case moment straddling the previous as well as the next day simultaneously. In 24-hour clockland, if you wish that instant in time to belong to the day that is ending, you write 24:00 (to denote midnight at the end of the calender day); on the other hand, if you desire the instant to belong to the following day, you write 00:00 (a much more common notation, but I suppose the former has its uses also). -- Thug: This is a stickup! Now come on. Your money or your life. [long pause] Thug: [repeating] Look, bud, I said, 'Your money or your life.' Jack Benny: I'm thinking, I'm thinking!
Re: Default date output format changed after an upgrade to buster
On Thursday, September 12, 2019 06:30:21 AM Dan Ritter wrote: > David Wright wrote: > > Even more astonishing is the fact that the US Government switched > > their am/pm meanings sometime between 2000 and 2008, which shows > > just how ambiguous they are. Wow! I believe that, I just didn't realize that (and I might have a rambling old man story / rant that I'll tell (below) about change (sometimes by government, sometimes by others). (I was going to try to avoid telling it, but I'm a rambling old man. By putting it at the end, it will be easy to ignore ;-) Regretfully, I always get confused. > There is only one sensible interpretation: > > If 11:59 AM is two minutes before 12:01 PM, then 12:00 is PM. @Dan Ritter -- I don't understand your logic -- oh, now I see, you consider 12 to be zero -- I have trouble seeing why sensible people wouldn't consider the next number after 11:59 to be 12? And why not: (no need to reply!) If 12:01 pm is two minutes after 11:59 am, then 12:00 is AM. But, ok, I'll try to burn that into my memory -- at night (when it is dark) 12:00 (midnight) is the beginning of morning (12:00 am). During the day, when it is light 12:00 (noon) is the beginning of night (12:00 pm). > If 11:59 PM is two minutes before 12:01 AM, then 12:00 is AM. > > The problem stems from 12 actually indicating what anybody > sensible would consider 0. > > -dsr- People in the US drive on the right hand side of the road (except for special cases like one way roads or such.) Some number of years ago, somebody (presumably a police commissioner or other high muckety much decided that, at the entrance and exit to the underground parking garage under our town's city hall complex, they would reverse that. Just crazy (imho). That could have been 20 years ago (or not, but it's been a long time). Fairly recently, somebody (who I credit with good sense) reversed it again -- of course, that caught be by surprise, but fortunately, no one was coming the other way. I'm not explicitly aware of accidents that occurred during the ~20 years while the entrance and exit were the other way, but I can imagine some confusion and close calls by drivers not used to that strangeness. (To try to clarify, there are two entrances / exits to the underground garage, you can enter or exit at either one.) Children in the US are (were??) taught to walk on the right (and adults to the extent adults might be taught to walk). Now I consider establishments like Walgreens, Rite-Aid, Walmart, and others to be foreign infiltrators, as, when they have an In and an Out door side by side, the In is on the left. (Ok, Walmart is only a halfway foreign infiltrator, as they typically have at least two entrances with In and Out doors, one of them has the In door on the left, the other has the In door on the right.) Regardless, when I got to Walmart, I enter the right hand door, whether it is marked in or out. If anybody complains, I tell them I am an American ;-) I avoid going to places like Walgreens, Rite-Aid, and similar unless I really have to.
Re: Default date output format changed after an upgrade to buster
David Wright wrote: > > What surprised me is the use of 12am and 12pm in the States. When > I was at grammar school (in the days of 12hour times), you lost > marks for writing either of these contradictions. It was either > 12 noon, 12 midnight, or 12 o'clock (where there's no ambiguity). 12 o'clock is the only one of those which is ambiguous. > Even more astonishing is the fact that the US Government switched > their am/pm meanings sometime between 2000 and 2008, which shows > just how ambiguous they are. There is only one sensible interpretation: If 11:59 AM is two minutes before 12:01 PM, then 12:00 is PM. If 11:59 PM is two minutes before 12:01 AM, then 12:00 is AM. The problem stems from 12 actually indicating what anybody sensible would consider 0. -dsr-
Re: Default date output format changed after an upgrade to buster
On Wed 11 Sep 2019 at 07:26:33 (-), Curt wrote: > On 2019-09-10, Sven Joachim wrote: > > On 2019-09-10 22:06 +0200, Rainer Dorsch wrote: > >> > >> after an upgrade from stretch to buster, the date default output changed > >> on my > >> system > >> > >> As an example: > >> > >> Tue Sep 10 19:50:26 CEST 2019 (stretch) > >> Tue 10 Sep 2019 09:26:33 PM CEST (buster) > >> > >> I am just wondering if this is a known issue or if another configuration > >> change > >> during the upgrade caused this. > > > > The default format very much depends on your locale. In the en_US.UTF-8 > > locale I also see the difference, but I think it's a bug fix. The > > buster output looks more like what an American user would expect. If > > you don't like it, set LC_TIME to something else, e.g. en_GB.UTF-8. > > You'd assume Americans would be less bewildered without the > "military-style" 24 clock (I remember old dad quizzing me when I was a > kid: "What time's 1700 hours?"), but then again our rather unique > habit of putting the month before the day (as in mm-dd-) is reversed > by the upgrade, so it seems to be a tie cultural imperialism-wise. What surprised me is the use of 12am and 12pm in the States. When I was at grammar school (in the days of 12hour times), you lost marks for writing either of these contradictions. It was either 12 noon, 12 midnight, or 12 o'clock (where there's no ambiguity). Even more astonishing is the fact that the US Government switched their am/pm meanings sometime between 2000 and 2008, which shows just how ambiguous they are. Cheers, David.
Re: Default date output format changed after an upgrade to buster
On Wednesday, September 11, 2019 09:14:19 AM Greg Wooledge wrote: > On Wed, Sep 11, 2019 at 09:07:10AM -0400, rhkra...@gmail.com wrote: > > On Wednesday, September 11, 2019 07:57:37 AM Michael Stone wrote: > > > those strings are expected to change depending on > > > things like locale settings, and are for humans to read, not programs. > > > > Interesting! I have no argument with what you say, it makes perfect > > sense, but it must be one of those things that "goes without saying" -- > > I can't claim to be a Linux guru, but in the years I've spent with Linux > > and with a fair amount of reading, I never saw that stated, nor was it > > ever implied enough for me to infer that (nor did I ever have occasion > > to run into a problem because of it (I am not the OP).) > > https://mywiki.wooledge.org/locale > https://wiki.debian.org/Locale > > If you're writing a program that parses the output of a command, you > typically will need to set LANG or LC_ALL to C somewhere in your > program, in order to get output in a predictable format. That's the sentence that would have been most meaningful / useful to me, and I would have needed to find that in all (or at least many of) the sources of documentation on how to write scripts or programs. (Now, sometimes I have selective attention, maybe it is there and I just glossed over it...) I'd need something to make me think there was a reason to look at locale when writing a script or program. (The only reason I found (that I can recall) to set a locale was to get a sort order that met my needs (usually meaning one that sorted uppercase and lowercase words and letters in a common sort order (not separated, uppercase in one place, lowercase in another). (Hmm, I vaguely recally that I once had to change the locale for some other reason, but that reason escapes me atm.)
Re: Default date output format changed after an upgrade to buster
On Wed, Sep 11, 2019 at 09:07:10AM -0400, rhkra...@gmail.com wrote: Interesting! I have no argument with what you say, it makes perfect sense, but it must be one of those things that "goes without saying" -- I can't claim to be a Linux guru, but in the years I've spent with Linux and with a fair amount of reading, I never saw that stated, nor was it ever implied enough for me to infer that (nor did I ever have occasion to run into a problem because of it (I am not the OP).) It's pretty clearly defined in the standards, but few people read them. :-)
Re: Default date output format changed after an upgrade to buster
On Wed, Sep 11, 2019 at 09:07:10AM -0400, rhkra...@gmail.com wrote: > On Wednesday, September 11, 2019 07:57:37 AM Michael Stone wrote: > > those strings are expected to change depending on > > things like locale settings, and are for humans to read, not programs. > > Interesting! I have no argument with what you say, it makes perfect sense, > but it must be one of those things that "goes without saying" -- I can't > claim > to be a Linux guru, but in the years I've spent with Linux and with a fair > amount of reading, I never saw that stated, nor was it ever implied enough > for > me to infer that (nor did I ever have occasion to run into a problem because > of it (I am not the OP).) https://mywiki.wooledge.org/locale https://wiki.debian.org/Locale If you're writing a program that parses the output of a command, you typically will need to set LANG or LC_ALL to C somewhere in your program, in order to get output in a predictable format.
Re: Default date output format changed after an upgrade to buster
On Wednesday, September 11, 2019 07:57:37 AM Michael Stone wrote: > apt-listchanges in what? If you run the stretch date on buster, you'll > get the same output. The change is that the localized string changed to > something more sensible and date uses the localized string. If a script > is relying on the output of a program like date without specifying > either the C locale or a date format, it's almost certainly doing > something wrong-- > those strings are expected to change depending on > things like locale settings, and are for humans to read, not programs. Interesting! I have no argument with what you say, it makes perfect sense, but it must be one of those things that "goes without saying" -- I can't claim to be a Linux guru, but in the years I've spent with Linux and with a fair amount of reading, I never saw that stated, nor was it ever implied enough for me to infer that (nor did I ever have occasion to run into a problem because of it (I am not the OP).) (I had a colleague who often felt that contracts included things that "go without saying" -- I tried to make it a practice to write those things into the contract. ;-) (Well, within reason, at least -- there are things like laws that govern contracts, and maybe well known conventions. ;-)
Re: Default date output format changed after an upgrade to buster
Am Mittwoch, 11. September 2019, 13:57:37 CEST schrieb Michael Stone: > On Wed, Sep 11, 2019 at 08:36:49AM +0200, Rainer Dorsch wrote: > >Am Dienstag, 10. September 2019, 22:52:03 CEST schrieb Greg Wooledge: > >> On Tue, Sep 10, 2019 at 10:06:37PM +0200, Rainer Dorsch wrote: > >> > after an upgrade from stretch to buster, the date default output > >> > changed > >> > on my system > >> > > >> > As an example: > >> > > >> > Tue Sep 10 19:50:26 CEST 2019 (stretch) > >> > Tue 10 Sep 2019 09:26:33 PM CEST (buster) > >> > > >> > I am just wondering if this is a known issue or if another > >> > configuration > >> > change during the upgrade caused this. > >> > >> https://www.mail-archive.com/debian-user@lists.debian.org/msg741032.html > > > >Many thanks for all the replies. Greg, the perfect explanation you already > >gave here > > > >https://www.mail-archive.com/debian-user@lists.debian.org/msg741096.html > > > >(that explains why buster behaves differently). > > > >I think it would have been worth an entry for apt-listchanges, since it > >might at least change the output of some local scripts (like it did here). > apt-listchanges in what? If you run the stretch date on buster, you'll > get the same output. The change is that the localized string changed to > something more sensible and date uses the localized string. If a script > is relying on the output of a program like date without specifying > either the C locale or a date format, it's almost certainly doing > something wrong--those strings are expected to change depending on > things like locale settings, and are for humans to read, not programs. Don't expect that all my scripts are perfect ... there are quick and dirty ones;-) In a logfile a human readable output sounds not a too bad idea though...but I understand attaching that change to date does not make sense. Nevermind, all good for me, I hope that if others are affected by the change they find the topic in the list archive. Thanks again Rainer -- Rainer Dorsch http://bokomoko.de/
Re: Default date output format changed after an upgrade to buster
On 2019-09-11 at 07:57, Michael Stone wrote: > On Wed, Sep 11, 2019 at 08:36:49AM +0200, Rainer Dorsch wrote: > >> Am Dienstag, 10. September 2019, 22:52:03 CEST schrieb Greg >> Wooledge: >>> https://www.mail-archive.com/debian-user@lists.debian.org/msg741032.html >> >> Many thanks for all the replies. Greg, the perfect explanation you >> already gave here >> >> https://www.mail-archive.com/debian-user@lists.debian.org/msg741096.html >> >> (that explains why buster behaves differently). >> >> I think it would have been worth an entry for apt-listchanges, >> since it might at least change the output of some local scripts >> (like it did here). > > apt-listchanges in what? Given that (as far as I'm aware) apt-listchanges just reports the changelog and NEWS entries from the various packages, the question should really be: a changelog or NEWS entry in what package, and what version of that package? In this case, the relevant package appears to be libc6, from the source package glibc. The changelog entry for glibc 2.28-5 mentions a backport of what looks to my eye like the patch which makes this change, albeit without mentioning what effect the change itself will have; to figure that out, you have to read the referenced (Debian) bug report, #877900. That patch appears to have been released upstream in glibc 2.29, which doesn't seem to have hit Debian testing yet. So I think the suggestion would have been that either the changelog or the NEWS entry from the Debian-packaged version of glibc which first included the patch which makes this change should have had a comment pointing out that the default date format for this common locale would change. > If a script is relying on the output of a program like date without > specifying either the C locale or a date format, it's almost > certainly doing something wrong--those strings are expected to > change depending on things like locale settings, and are for humans > to read, not programs. This is quite true, however. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Default date output format changed after an upgrade to buster
On Wed, Sep 11, 2019 at 08:36:49AM +0200, Rainer Dorsch wrote: Am Dienstag, 10. September 2019, 22:52:03 CEST schrieb Greg Wooledge: On Tue, Sep 10, 2019 at 10:06:37PM +0200, Rainer Dorsch wrote: > after an upgrade from stretch to buster, the date default output changed > on my system > > As an example: > > Tue Sep 10 19:50:26 CEST 2019 (stretch) > Tue 10 Sep 2019 09:26:33 PM CEST (buster) > > I am just wondering if this is a known issue or if another configuration > change during the upgrade caused this. https://www.mail-archive.com/debian-user@lists.debian.org/msg741032.html Many thanks for all the replies. Greg, the perfect explanation you already gave here https://www.mail-archive.com/debian-user@lists.debian.org/msg741096.html (that explains why buster behaves differently). I think it would have been worth an entry for apt-listchanges, since it might at least change the output of some local scripts (like it did here). apt-listchanges in what? If you run the stretch date on buster, you'll get the same output. The change is that the localized string changed to something more sensible and date uses the localized string. If a script is relying on the output of a program like date without specifying either the C locale or a date format, it's almost certainly doing something wrong--those strings are expected to change depending on things like locale settings, and are for humans to read, not programs.
Re: Default date output format changed after an upgrade to buster
On 2019-09-11, Curt wrote: > On 2019-09-10, Sven Joachim wrote: >> On 2019-09-10 22:06 +0200, Rainer Dorsch wrote: >> >>> Hi, >>> >>> after an upgrade from stretch to buster, the date default output changed on >>> my >>> system >>> >>> As an example: >>> >>> Tue Sep 10 19:50:26 CEST 2019 (stretch) >>> Tue 10 Sep 2019 09:26:33 PM CEST (buster) >>> >>> I am just wondering if this is a known issue or if another configuration >>> change >>> during the upgrade caused this. >> >> The default format very much depends on your locale. In the en_US.UTF-8 >> locale I also see the difference, but I think it's a bug fix. The >> buster output looks more like what an American user would expect. If >> you don't like it, set LC_TIME to something else, e.g. en_GB.UTF-8. > > You'd assume Americans would be less bewildered without the > "military-style" 24 clock (I remember old dad quizzing me when I was a 24-hour clock > kid: "What time's 1700 hours?"), but then again our rather unique > habit of putting the month before the day (as in mm-dd-) is reversed > by the upgrade, so it seems to be a tie cultural imperialism-wise. > >> Cheers, >>Sven >> >> > > -- Thug: This is a stickup! Now come on. Your money or your life. [long pause] Thug: [repeating] Look, bud, I said, 'Your money or your life.' Jack Benny: I'm thinking, I'm thinking!
Re: Default date output format changed after an upgrade to buster
On 2019-09-10, Sven Joachim wrote: > On 2019-09-10 22:06 +0200, Rainer Dorsch wrote: > >> Hi, >> >> after an upgrade from stretch to buster, the date default output changed on >> my >> system >> >> As an example: >> >> Tue Sep 10 19:50:26 CEST 2019 (stretch) >> Tue 10 Sep 2019 09:26:33 PM CEST (buster) >> >> I am just wondering if this is a known issue or if another configuration >> change >> during the upgrade caused this. > > The default format very much depends on your locale. In the en_US.UTF-8 > locale I also see the difference, but I think it's a bug fix. The > buster output looks more like what an American user would expect. If > you don't like it, set LC_TIME to something else, e.g. en_GB.UTF-8. You'd assume Americans would be less bewildered without the "military-style" 24 clock (I remember old dad quizzing me when I was a kid: "What time's 1700 hours?"), but then again our rather unique habit of putting the month before the day (as in mm-dd-) is reversed by the upgrade, so it seems to be a tie cultural imperialism-wise. > Cheers, >Sven > > -- Thug: This is a stickup! Now come on. Your money or your life. [long pause] Thug: [repeating] Look, bud, I said, 'Your money or your life.' Jack Benny: I'm thinking, I'm thinking!
Re: Default date output format changed after an upgrade to buster
Am Dienstag, 10. September 2019, 22:52:03 CEST schrieb Greg Wooledge: > On Tue, Sep 10, 2019 at 10:06:37PM +0200, Rainer Dorsch wrote: > > after an upgrade from stretch to buster, the date default output changed > > on my system > > > > As an example: > > > > Tue Sep 10 19:50:26 CEST 2019 (stretch) > > Tue 10 Sep 2019 09:26:33 PM CEST (buster) > > > > I am just wondering if this is a known issue or if another configuration > > change during the upgrade caused this. > > https://www.mail-archive.com/debian-user@lists.debian.org/msg741032.html Many thanks for all the replies. Greg, the perfect explanation you already gave here https://www.mail-archive.com/debian-user@lists.debian.org/msg741096.html (that explains why buster behaves differently). I think it would have been worth an entry for apt-listchanges, since it might at least change the output of some local scripts (like it did here). Thanks again Rainer -- Rainer Dorsch http://bokomoko.de/
Re: Default date output format changed after an upgrade to buster
On 2019-09-10 22:06 +0200, Rainer Dorsch wrote: > Hi, > > after an upgrade from stretch to buster, the date default output changed on my > system > > As an example: > > Tue Sep 10 19:50:26 CEST 2019 (stretch) > Tue 10 Sep 2019 09:26:33 PM CEST (buster) > > I am just wondering if this is a known issue or if another configuration > change > during the upgrade caused this. The default format very much depends on your locale. In the en_US.UTF-8 locale I also see the difference, but I think it's a bug fix. The buster output looks more like what an American user would expect. If you don't like it, set LC_TIME to something else, e.g. en_GB.UTF-8. Cheers, Sven
Re: Default date output format changed after an upgrade to buster
On Tue, Sep 10, 2019 at 10:06:37PM +0200, Rainer Dorsch wrote: after an upgrade from stretch to buster, the date default output changed on my system As an example: Tue Sep 10 19:50:26 CEST 2019 (stretch) Tue 10 Sep 2019 09:26:33 PM CEST (buster) I am just wondering if this is a known issue or if another configuration change during the upgrade caused this. date shows a localized string by default. Try env LANG=C date if you want the traditional posix format.
Re: Default date output format changed after an upgrade to buster
On Tue, Sep 10, 2019 at 10:06:37PM +0200, Rainer Dorsch wrote: > after an upgrade from stretch to buster, the date default output changed on > my > system > > As an example: > > Tue Sep 10 19:50:26 CEST 2019 (stretch) > Tue 10 Sep 2019 09:26:33 PM CEST (buster) > > I am just wondering if this is a known issue or if another configuration > change > during the upgrade caused this. https://www.mail-archive.com/debian-user@lists.debian.org/msg741032.html
