Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #270113 > unrolled thread
| Started by | Keith Bainbridge <keithrbau@gmail.com> |
|---|---|
| First post | 2024-06-16 10:20 +0200 |
| Last post | 2024-06-17 11:00 +0200 |
| Articles | 20 on this page of 125 — 25 participants |
Back to article view | Back to linux.debian.user
Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-16 10:20 +0200
Re: Maximum size .bash_aliases file Richard <rrosner5@gmail.com> - 2024-06-16 15:30 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-17 10:50 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-16 16:00 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-17 10:30 +0200
Re: Maximum size .bash_aliases file gene heskett <gheskett@shentel.net> - 2024-06-17 13:00 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-17 13:30 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-18 10:30 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-18 13:10 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-22 10:00 +0200
Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-17 16:20 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-17 16:30 +0200
Time, was Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-17 17:40 +0200
Re: Time, was Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-17 17:50 +0200
Re: Time, was Re: Maximum size .bash_aliases file eben@gmx.us - 2024-06-17 19:30 +0200
Re: Time, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-22 10:10 +0200
Re: Time, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-22 10:10 +0200
Re: Maximum size .bash_aliases file <tomas@tuxteam.de> - 2024-06-17 18:30 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-17 19:30 +0200
Re: Maximum size .bash_aliases file <tomas@tuxteam.de> - 2024-06-17 19:50 +0200
System time/timezone, was Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-18 07:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file <tomas@tuxteam.de> - 2024-06-18 10:10 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Jeffrey Walton <noloader@gmail.com> - 2024-06-18 10:20 +0200
RTC, was Re: System time/timezone David Wright <deblis@lionunicorn.co.uk> - 2024-06-19 06:10 +0200
Re: RTC, was Re: System time/timezone Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-06-19 21:20 +0200
Re: RTC, was Re: System time/timezone Greg Wooledge <greg@wooledge.org> - 2024-06-19 21:40 +0200
Re: RTC, was Re: System time/timezone Stefan Monnier <monnier@iro.umontreal.ca> - 2024-06-20 04:00 +0200
Re: RTC, was Re: System time/timezone Max Nikulin <manikulin@gmail.com> - 2024-06-20 04:00 +0200
Re: RTC, was Re: System time/timezone Keith Bainbridge <keithrbau@gmail.com> - 2024-06-22 10:20 +0200
Re: RTC, was Re: System time/timezone Michael Stone <mstone@debian.org> - 2024-06-20 05:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-19 06:10 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file <tomas@tuxteam.de> - 2024-06-19 06:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-18 13:10 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-19 06:10 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-19 13:10 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Jeffrey Walton <noloader@gmail.com> - 2024-06-19 19:10 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file <tomas@tuxteam.de> - 2024-06-20 07:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Jeffrey Walton <noloader@gmail.com> - 2024-06-20 07:30 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file tomas@tuxteam.de - 2024-06-20 08:30 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Max Nikulin <manikulin@gmail.com> - 2024-06-21 04:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-21 05:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file <tomas@tuxteam.de> - 2024-06-21 06:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-22 17:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Stefan Monnier <monnier@iro.umontreal.ca> - 2024-06-22 18:10 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-06-23 04:10 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-23 05:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-23 06:30 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-23 07:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file gene heskett <gheskett@shentel.net> - 2024-06-23 08:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file eben@gmx.us - 2024-06-23 15:30 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file gene heskett <gheskett@shentel.net> - 2024-06-23 16:30 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-26 02:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file eben@gmx.us - 2024-06-26 15:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Curt <curty@free.fr> - 2024-06-24 15:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Curt <curty@free.fr> - 2024-06-24 15:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Bret Busby <bret@busby.net> - 2024-06-24 17:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Heriberto Avelino <heriberto.avelino@gmail.com> - 2024-06-26 00:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Bret Busby <bret@busby.net> - 2024-06-24 17:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file eben@gmx.us - 2024-06-24 18:10 +0200
Re: System time/timezone Felix Miata <mrmazda@earthlink.net> - 2024-06-24 18:20 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file The Wanderer <wanderer@fastmail.fm> - 2024-06-25 00:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file John Hasler <john@sugarbit.com> - 2024-06-25 00:20 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file The Wanderer <wanderer@fastmail.fm> - 2024-06-25 00:30 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file "Andrew M.A. Cater" <amacater@einval.com> - 2024-06-25 10:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file debian-user@howorth.org.uk - 2024-06-26 12:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file John Hasler <john@sugarbit.com> - 2024-06-26 18:30 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-26 19:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-28 06:20 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Erwan DAVID <erwan@rail.eu.org> - 2024-06-28 07:10 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file John Crawley <john@bunsenlabs.org> - 2024-06-28 08:30 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-28 11:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file John Crawley <john@bunsenlabs.org> - 2024-06-30 03:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-06-25 20:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-25 21:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-26 03:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-26 02:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-26 02:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-23 14:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-24 02:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Curt <curty@free.fr> - 2024-06-23 17:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-26 02:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-21 13:20 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-22 17:00 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-22 18:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-23 06:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Jeffrey Walton <noloader@gmail.com> - 2024-06-23 07:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file <tomas@tuxteam.de> - 2024-06-21 06:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Max Nikulin <manikulin@gmail.com> - 2024-06-22 05:30 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file <tomas@tuxteam.de> - 2024-06-22 07:30 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file <tomas@tuxteam.de> - 2024-06-22 17:20 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-23 04:40 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-23 05:10 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file John Hasler <john@sugarbit.com> - 2024-06-23 21:50 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-26 02:30 +0200
Re: System time/timezone, was Re: Maximum size .bash_aliases file Stefan Monnier <monnier@iro.umontreal.ca> - 2024-06-20 04:00 +0200
time display was: Re: Maximum size .bash_aliases file debian-user@howorth.org.uk - 2024-06-17 17:00 +0200
Re: time display was: Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-17 17:10 +0200
Re: time display was: Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-22 10:20 +0200
Re: time display was: Re: Maximum size .bash_aliases file Default User <hunguponcontent@gmail.com> - 2024-06-22 16:30 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-20 13:10 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-20 13:20 +0200
Re: Maximum size .bash_aliases file The Wanderer <wanderer@fastmail.fm> - 2024-06-20 13:30 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-22 10:30 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-22 16:10 +0200
Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-21 06:30 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-22 10:40 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-22 16:10 +0200
Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-22 17:00 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-22 18:30 +0200
Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-23 06:30 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-25 10:40 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-25 13:20 +0200
Re: Maximum size .bash_aliases file debian-user@howorth.org.uk - 2024-06-25 14:30 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-25 15:00 +0200
Australia/Eucla timezone abbreviation (was: Re: Maximum size .bash_aliases file) Max Nikulin <manikulin@gmail.com> - 2024-06-25 17:20 +0200
Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-22 17:10 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-25 10:50 +0200
Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-17 06:40 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-17 10:50 +0200
Re: Maximum size .bash_aliases file <tomas@tuxteam.de> - 2024-06-17 11:20 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-17 14:10 +0200
Re: Maximum size .bash_aliases file <tomas@tuxteam.de> - 2024-06-17 14:20 +0200
Re: Maximum size .bash_aliases file Greg Wooledge <greg@wooledge.org> - 2024-06-17 13:30 +0200
Re: Maximum size .bash_aliases file David Wright <deblis@lionunicorn.co.uk> - 2024-06-17 17:50 +0200
Re: Maximum size .bash_aliases file Keith Bainbridge <keithrbau@gmail.com> - 2024-06-17 11:00 +0200
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-06-20 13:20 +0200 |
| Message-ID | <IRnZD-4gEV-3@gated-at.bofh.it> |
| In reply to | #270297 |
On Thu, Jun 20, 2024 at 21:00:38 +1000, Keith Bainbridge wrote: > https://manpages.debian.org/bookworm/manpages-dev/strftime.3.en.html > > is a list of place names for MANY parts of a date layout. I have set up the > following code in my text substitution app: > "%a %d%b%Y at %H:%M:%S =UTC %Z" > > Triggering that give me > Thu 20Jun2024 at 20:51:19 =UTC +10:00 > > Seems to me that if the code writers of our various MUA would add the +UTC > to the line that prints the various dates, we'd understand what they mean > better. Honestly, I have no idea what the =UTC part of your output is intended to mean, since you've got +10:00 (time zone offset specification in hours ahead of UTC) overriding it. Normally, you put either the string UTC to indicate that this date/time string is in UTC, or a time zone offset indicator that begins with + or -. Not both.
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2024-06-20 13:30 +0200 |
| Message-ID | <IRo9m-4gIi-7@gated-at.bofh.it> |
| In reply to | #270298 |
[Multipart message — attachments visible in raw view] — view raw
On 2024-06-20 at 07:10, Greg Wooledge wrote: > On Thu, Jun 20, 2024 at 21:00:38 +1000, Keith Bainbridge wrote: > >> https://manpages.debian.org/bookworm/manpages-dev/strftime.3.en.html >> >> is a list of place names for MANY parts of a date layout. I have set up the >> following code in my text substitution app: >> "%a %d%b%Y at %H:%M:%S =UTC %Z" >> >> Triggering that give me >> Thu 20Jun2024 at 20:51:19 =UTC +10:00 >> >> Seems to me that if the code writers of our various MUA would add the +UTC >> to the line that prints the various dates, we'd understand what they mean >> better. > > Honestly, I have no idea what the =UTC part of your output is intended > to mean, since you've got +10:00 (time zone offset specification in hours > ahead of UTC) overriding it. I parsed it as meaning "[date and time] is equal to UTC plus ten hours", or in other words, "the time specified is in the UTC+10 time-zone". Similarly to how I often seen Eastern Standard Time referenced as UTC-4 (that is, UTC minus four hours). > Normally, you put either the string UTC to indicate that this date/time > string is in UTC, or a time zone offset indicator that begins with + or -. > Not both. It may be notable that he didn't put a +- offset indicator; he put a format specifier which *expands to* whichever such indicator would correspond to the active time zone. -- 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
[toc] | [prev] | [next] | [standalone]
| From | Keith Bainbridge <keithrbau@gmail.com> |
|---|---|
| Date | 2024-06-22 10:30 +0200 |
| Message-ID | <IS4id-4Hj4-1@gated-at.bofh.it> |
| In reply to | #270300 |
On 20/6/24 21:19, The Wanderer wrote: > On 2024-06-20 at 07:10, Greg Wooledge wrote: > >> On Thu, Jun 20, 2024 at 21:00:38 +1000, Keith Bainbridge wrote: >> >>> https://manpages.debian.org/bookworm/manpages-dev/strftime.3.en.html >>> >>> is a list of place names for MANY parts of a date layout. I have set up the >>> following code in my text substitution app: >>> "%a %d%b%Y at %H:%M:%S =UTC %Z" >>> >>> Triggering that give me >>> Thu 20Jun2024 at 20:51:19 =UTC +10:00 >>> >>> Seems to me that if the code writers of our various MUA would add the +UTC >>> to the line that prints the various dates, we'd understand what they mean >>> better. >> >> Honestly, I have no idea what the =UTC part of your output is intended >> to mean, since you've got +10:00 (time zone offset specification in hours >> ahead of UTC) overriding it. > > I parsed it as meaning "[date and time] is equal to UTC plus ten hours", > or in other words, "the time specified is in the UTC+10 time-zone". > Similarly to how I often seen Eastern Standard Time referenced as UTC-4 > (that is, UTC minus four hours). > >> Normally, you put either the string UTC to indicate that this date/time >> string is in UTC, or a time zone offset indicator that begins with + or -. >> Not both. > > It may be notable that he didn't put a +- offset indicator; he put a > format specifier which *expands to* whichever such indicator would > correspond to the active time zone. > And doesn't this exchange show that Sat 22Jun2024 at 18:27:55 +10:00 can be interpreted in two ways? -- All the best Keith Bainbridge keithrbau@gmail.com keith.bainbridge.3216@gmail.com +61 (0)447 667 468 UTC + 10:00
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-06-22 16:10 +0200 |
| Message-ID | <IS9Bf-4KFs-7@gated-at.bofh.it> |
| In reply to | #270361 |
On Sat, Jun 22, 2024 at 18:28:55 +1000, Keith Bainbridge wrote: > And doesn't this exchange show that > Sat 22Jun2024 at 18:27:55 +10:00 > > can be interpreted in two ways? I can only read it one way. What other way are you thinking of?
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-06-21 06:30 +0200 |
| Message-ID | <IRE4q-4qKE-3@gated-at.bofh.it> |
| In reply to | #270297 |
On Thu 20 Jun 2024 at 21:00:38 (+1000), Keith Bainbridge wrote: > On 17/6/24 18:26, Keith Bainbridge wrote: > > > > It was late afternoon on 16Jun2024 that I wrote this. Possibly > > 18:13:36 when I pressed send. I'd reckon it would likely have been > > 08:13:36 UTC What's wrong with my system clock. I've not really > > looked at the time on my originals before. I'll try to remember > > to enter my local time as I press send > > Thanks for those responses. [ … ] > > I reskon that they seem to indicate that the date/time in my original > question are fine. the difficulty is more related to how we humans are > interpreting the information we are reading. > > https://manpages.debian.org/bookworm/manpages-dev/strftime.3.en.html > > is a list of place names for MANY parts of a date layout. I have set > up the following code in my text substitution app: > "%a %d%b%Y at %H:%M:%S =UTC %Z" > > Triggering that give me > Thu 20Jun2024 at 20:51:19 =UTC +10:00 > > Seems to me that if the code writers of our various MUA would add the > +UTC to the line that prints the various dates, we'd understand what > they mean better. > > Meantime, we have to accept what we have. You could pronounce your time written above as: "It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00" if that's indeed your intention. But what you've done is invent some notation of your own, which people will likely misunderstand. I think it best to look up these references and follow them: https://en.wikipedia.org/wiki/ISO_8601 https://www.ietf.org/rfc/rfc3339.txt IMHO I think that email attributions are best presented in and with the time zone of the sender, and not oneself. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Keith Bainbridge <keithrbau@gmail.com> |
|---|---|
| Date | 2024-06-22 10:40 +0200 |
| Message-ID | <IS4rT-4Hmq-3@gated-at.bofh.it> |
| In reply to | #270332 |
On 21/6/24 14:28, David Wright wrote: > You could pronounce your time written above as: > > "It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00" Excellent. Now how do we get our MUA to do that when replying to mail, which is where I saw what I thought was a system error - but in fact was a misinterpretation. > > if that's indeed your intention. But what you've done is invent > some notation of your own, which people will likely misunderstand. > > I think it best to look up these references and follow them: > > https://en.wikipedia.org/wiki/ISO_8601 > https://www.ietf.org/rfc/rfc3339.txt Will do > > IMHO I think that email attributions are best presented in and with > the time zone of the sender, and not oneself. Maybe that would be achieved if the replyer's MUA inserted the senders date/time more clearly. I don't mean to harp on, but maybe the coders just haven't mis-read the dates they are inserting for us. > > Cheers, > David. -- All the best Keith Bainbridge keithrbau@gmail.com keith.bainbridge.3216@gmail.com +61 (0)447 667 468 UTC + 10:00
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-06-22 16:10 +0200 |
| Message-ID | <IS9Bf-4KFs-3@gated-at.bofh.it> |
| In reply to | #270362 |
On Sat, Jun 22, 2024 at 18:35:34 +1000, Keith Bainbridge wrote:
>
> On 21/6/24 14:28, David Wright wrote:
> > You could pronounce your time written above as:
> >
> > "It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00"
>
> Excellent. Now how do we get our MUA to do that when replying to mail,
Depends on your MUA. In mutt, it would be:
set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z"
except that this won't put a colon inside the timezone offset. It
would just end with "UTC+1000".
Of course, you probably don't want that exact wording, because it's
used as *part* of the attribution. If you used the above, then the
attribution would come out looking like:
On It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+1000, So-and-So wrote:
So, you'd either want to change the attribution variable as well, or
alter that wording slightly. I'd suggest removing "It's" and "here".
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-06-22 17:00 +0200 |
| Message-ID | <ISanD-4KWa-5@gated-at.bofh.it> |
| In reply to | #270369 |
On Sat 22 Jun 2024 at 10:02:43 (-0400), Greg Wooledge wrote:
> On Sat, Jun 22, 2024 at 18:35:34 +1000, Keith Bainbridge wrote:
> > On 21/6/24 14:28, David Wright wrote:
> > > You could pronounce your time written above as:
> > >
> > > "It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00"
> >
> > Excellent. Now how do we get our MUA to do that when replying to mail,
>
> Depends on your MUA. In mutt, it would be:
>
> set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z"
>
> except that this won't put a colon inside the timezone offset. It
> would just end with "UTC+1000".
>
> Of course, you probably don't want that exact wording, because it's
> used as *part* of the attribution. If you used the above, then the
> attribution would come out looking like:
>
> On It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+1000, So-and-So wrote:
>
> So, you'd either want to change the attribution variable as well, or
> alter that wording slightly. I'd suggest removing "It's" and "here".
I think you need to set attribution, not date_format. For example,
set attribution="On %{%a %d %b %Y} at %{%H:%M:%S (%z)}, %n wrote:"
is my own. The %{…} braces indicate using the sender's time zone.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-06-22 18:30 +0200 |
| Message-ID | <ISbMK-4LVD-9@gated-at.bofh.it> |
| In reply to | #270373 |
On Sat, Jun 22, 2024 at 09:51:32 -0500, David Wright wrote:
> On Sat 22 Jun 2024 at 10:02:43 (-0400), Greg Wooledge wrote:
> > set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z"
> I think you need to set attribution, not date_format. For example,
> set attribution="On %{%a %d %b %Y} at %{%H:%M:%S (%z)}, %n wrote:"
> is my own. The %{…} braces indicate using the sender's time zone.
The default value of attribution contains %d which references the
date_format variable. The "!" in the date_format variable says to
use the C locale when writing the day-of-week and month abbreviations,
rather than whatever your regular locale would call them.
I'm using this:
set date_format="!%a, %b %d, %Y at %H:%M:%S %z"
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-06-23 06:30 +0200 |
| Message-ID | <ISn1v-4Tkp-5@gated-at.bofh.it> |
| In reply to | #270379 |
On Sat 22 Jun 2024 at 12:26:05 (-0400), Greg Wooledge wrote:
> On Sat, Jun 22, 2024 at 09:51:32 -0500, David Wright wrote:
> > On Sat 22 Jun 2024 at 10:02:43 (-0400), Greg Wooledge wrote:
> > > set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z"
>
> > I think you need to set attribution, not date_format. For example,
> > set attribution="On %{%a %d %b %Y} at %{%H:%M:%S (%z)}, %n wrote:"
> > is my own. The %{…} braces indicate using the sender's time zone.
>
> The default value of attribution contains %d which references the
> date_format variable. The "!" in the date_format variable says to
> use the C locale when writing the day-of-week and month abbreviations,
> rather than whatever your regular locale would call them.
>
> I'm using this:
>
> set date_format="!%a, %b %d, %Y at %H:%M:%S %z"
I didn't mean that it won't work.
The attribution format is designed for the benefit of recipients.
The date_format is designed to be available for constructing
strings like indexes and folder lists for the user, as well as
external-facing uses. You might want to add text like "where clocks
are" to the top of a message, but it would be tedious to have a
column of
where clocks are
where clocks are
where clocks are
where clocks are
in an index.
Cheers,
David.
[toc] | [prev] | [next] | [standalone]
| From | Keith Bainbridge <keithrbau@gmail.com> |
|---|---|
| Date | 2024-06-25 10:40 +0200 |
| Message-ID | <IT9Sx-5qGG-3@gated-at.bofh.it> |
| In reply to | #270369 |
On 23/6/24 00:02, Greg Wooledge wrote: > In mutt, it would be: > > set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z" I believe UTC%Z will give the : as I get from my text expander. Tue 25Jun2024 at 18:34:20 =UTC +10:00 -- All the best Keith Bainbridge keithrbau@gmail.com keith.bainbridge.3216@gmail.com +61 (0)447 667 468 UTC + 10:00
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-06-25 13:20 +0200 |
| Message-ID | <ITcnn-5sEV-1@gated-at.bofh.it> |
| In reply to | #270458 |
On Tue, Jun 25, 2024 at 18:35:00 +1000, Keith Bainbridge wrote:
> On 23/6/24 00:02, Greg Wooledge wrote:
> > In mutt, it would be:
> >
> > set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z"
>
> I believe UTC%Z will give the :
>
> as I get from my text expander.
>
> Tue 25Jun2024 at 18:34:20 =UTC +10:00
Well, maybe it does. The strftime(3) documentation doesn't support
that, though:
%z The +hhmm or -hhmm numeric timezone (that is, the hour and
minute offset from UTC). (SU)
%Z The timezone name or abbreviation.
In my experience, the "timezone name or abbreviation" is useless to
anyone who doesn't live in or near that time zone, particularly since
you cannot use it as the value of a TZ variable to ask date(1) what
time it is in that time zone.
On my system, at this time of year, it prints "EDT".
hobbit:~$ printf '%(%z %Z)T\n' -1
-0400 EDT
Bash's builtin printf, when using the %(fmt)T specifier, is documented
to call strftime(3), just like mutt's date_format. So I consider this
a valid test, without needing to write a C program, or change my
date_format variable.
Here's another test:
hobbit:~$ TZ=Australia/Eucla printf '%(%z %Z)T\n' -1
+0845 +0845
[toc] | [prev] | [next] | [standalone]
| From | debian-user@howorth.org.uk |
|---|---|
| Date | 2024-06-25 14:30 +0200 |
| Message-ID | <ITdt8-5tsv-1@gated-at.bofh.it> |
| In reply to | #270462 |
Greg Wooledge <greg@wooledge.org> wrote: > Here's another test: > > hobbit:~$ TZ=Australia/Eucla printf '%(%z %Z)T\n' -1 > +0845 +0845 That seems like a bug. I'd have expected: +0845 ACWST
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-06-25 15:00 +0200 |
| Message-ID | <ITdW9-5tHi-3@gated-at.bofh.it> |
| In reply to | #270464 |
On Tue, Jun 25, 2024 at 13:25:10 +0100, debian-user@howorth.org.uk wrote: > Greg Wooledge <greg@wooledge.org> wrote: > > Here's another test: > > > > hobbit:~$ TZ=Australia/Eucla printf '%(%z %Z)T\n' -1 > > +0845 +0845 > > That seems like a bug. I'd have expected: > > +0845 ACWST My guess is the time zone names are provided (or not provided) by libc, and in this case one is not being provided, so it falls back to the %z response. If this guess is correct, then you could file a bug against the libc6 package. There might be layers I don't understand. Maybe it's related to generated locales or something. In that case, the result would depend on which locales I have generated on my system. Do you get a different result? If so, can you explain why?
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-06-25 17:20 +0200 |
| Subject | Australia/Eucla timezone abbreviation (was: Re: Maximum size .bash_aliases file) |
| Message-ID | <ITg7D-5vAc-3@gated-at.bofh.it> |
| In reply to | #270464 |
On 25/06/2024 19:25, debian-user@howorth.org.uk wrote: > Greg Wooledge wrote: >> Here's another test: >> >> hobbit:~$ TZ=Australia/Eucla printf '%(%z %Z)T\n' -1 >> +0845 +0845 > > That seems like a bug. I'd have expected: > > +0845 ACWST It was an intentional change, "+0845" is the abbreviation. That time it caused issues with e.g. tzdata parser in Qt that did not expect numbers in this field. https://github.com/eggert/tz a25d6154 2017-02-10 10:53:47 -0800 Paul Eggert: Remove many invented abbreviations in 'australasia' > diff --git a/australasia b/australasia > index 0bca53e2..12800223 100644 > --- a/australasia > +++ b/australasia > @@ -44,8 +44,8 @@ Zone Australia/Perth 7:43:24 - LMT 1895 Dec > 8:00 Aus AW%sT 1943 Jul > 8:00 AW AW%sT > Zone Australia/Eucla 8:35:28 - LMT 1895 Dec > - 8:45 Aus ACW%sT 1943 Jul > - 8:45 AW ACW%sT > + 8:45 Aus +0845/+0945 1943 Jul > + 8:45 AW +0845/+0945
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-06-22 17:10 +0200 |
| Message-ID | <ISaxk-4LeV-15@gated-at.bofh.it> |
| In reply to | #270362 |
On Sat 22 Jun 2024 at 18:35:34 (+1000), Keith Bainbridge wrote: > On 21/6/24 14:28, David Wright wrote: > > You could pronounce your time written above as: > > > > "It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00" > > Excellent. Now how do we get our MUA to do that when replying to mail, > which is where I saw what I thought was a system error - but in fact > was a misinterpretation. I don't see the point. The email has a "Date:" header. Unless it's significant that your email is like a blog that's been written over a period of time; chronicling current events, say. > > if that's indeed your intention. But what you've done is invent > > some notation of your own, which people will likely misunderstand. > > > > I think it best to look up these references and follow them: > > > > https://en.wikipedia.org/wiki/ISO_8601 > > https://www.ietf.org/rfc/rfc3339.txt > > Will do > > > > IMHO I think that email attributions are best presented in and with > > the time zone of the sender, and not oneself. > > Maybe that would be achieved if the replyer's MUA inserted the senders > date/time more clearly. I don't mean to harp on, but maybe the > coders just haven't mis-read the dates they are inserting for us. They write Date: in the same format, often called RFC822 format, see RFC 2822. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Keith Bainbridge <keithrbau@gmail.com> |
|---|---|
| Date | 2024-06-25 10:50 +0200 |
| Message-ID | <ITa2d-5qKe-1@gated-at.bofh.it> |
| In reply to | #270376 |
On 23/6/24 00:52, David Wright wrote: >> Excellent. Now how do we get our MUA to do that when replying to mail, >> which is where I saw what I thought was a system error - but in fact >> was a misinterpretation. > I don't see the point. The email has a "Date:" header. Sounds like I'm the only one who mis-read the date format when I raised the query originally. Is David writing at 00:52 or is that time UTC? -- All the best Keith Bainbridge keithrbau@gmail.com keith.bainbridge.3216@gmail.com +61 (0)447 667 468 UTC + 10:00
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-06-17 06:40 +0200 |
| Message-ID | <IQcjT-3uSR-1@gated-at.bofh.it> |
| In reply to | #270113 |
Just some random thoughts: On Sun 16 Jun 2024 at 18:13:36 (+1000), Keith Bainbridge wrote: > > Some of my aliases stopped working after months of working as I > expected. And udating the .bash_aliases kept giving me an error > referring to an end of file before the matching ' in one of the last > aliases. So I did some searching. All the aliases that lie textually after the one with the missing ' will remain undefined, so you can use bisection to locate where in the file problem lies. > So, is an alias a form of variable? I had about 150 plus 4 functions There's little chance of hitting bash's limits unless you're generating the aliases or functions programmatically, and they'd need naming systematically for you to be able to remember them all. > So I re-did my .bash_aliases file with only the bits I NEED; and all > is back to normal. It looks like the error was in something that you judged you didn't need, and you removed it. > When I got my aliases working, I checked the size of the old file - > 17K. The new .bash_aliases is 2.5K with .bash_functions at 490B. In any case, the bash limits you quoted were concerned with the number of definitions, not the size of the files containing them. Interesting that your aliases are on average as big as your functions. About 90 of my aliases occupy 3.5k, whereas ~350 functions occupy 240k, so averaging around 40 and 680 characters each, respectively. > The errant function that failed after a little satisfactory use was to > mount a USB and back it up to my system. It is used to run portable > apps at a volunteer job - yes windows. I noticed that the sample > functions on the web didn't have && for each line, so I removed them > and performance is now back to what I expected. The errant line was > the mount cmd. Originally if I had already mounted the USB, the > function kept going. I don't recall adding the &&, so it didn't dawn > on me to try removing them. (I worked around it by unmounting it (an > alias) and trying the back-up again.) I don't follow what this is about, particularly each line having (or not having) a &&. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Keith Bainbridge <keithrbau@gmail.com> |
|---|---|
| Date | 2024-06-17 10:50 +0200 |
| Message-ID | <IQgdP-3xFP-3@gated-at.bofh.it> |
| In reply to | #270141 |
On 17/6/24 14:20, David Wright wrote: > Just some random thoughts: > > On Sun 16 Jun 2024 at 18:13:36 (+1000), Keith Bainbridge wrote: >> >> Some of my aliases stopped working after months of working as I >> expected. And udating the .bash_aliases kept giving me an error >> referring to an end of file before the matching ' in one of the last >> aliases. So I did some searching. Thanks David, > > All the aliases that lie textually after the one with the missing ' > will remain undefined, so you can use bisection to locate where in > the file problem lies. If I didn't use a syntax matching editor this may have easily been my problem. This is the line that was being reported as the incomplete alias, and a few that follow it: alias srb='source /home/keith/.bashrc' #alias srz='source ~/.zshrc' alias rcrt='sudo crontab -e ' alias kcrt='crontab -e' The editor changes the colour of the text from the opening ' to the next ' in the file. If that is the next alias while I am inserting a new one mid-file, the colour corrects when I type the closing ' That colour diff doesn't show here, but does in the editor - in the file I re-named for now. I can see nothing different in the formatting of the reported error line from any others. And the supposed error worked from the moment I pasted it to the new file and ran source .bashrc One thing that still puzzles me is that when I #'d the errant line and source .bashrc the error still reported the same line Number - even when #'d out. > >> So, is an alias a form of variable? I had about 150 plus 4 functions > > There's little chance of hitting bash's limits unless you're > generating the aliases or functions programmatically, and they'd > need naming systematically for you to be able to remember them all. > As I said to Greg - I don't understand this; so I don't know how I would have done it. >> So I re-did my .bash_aliases file with only the bits I NEED; and all >> is back to normal. > > It looks like the error was in something that you judged you didn't need, > and you removed it. No. The alias worked as soon as I activated it > >> When I got my aliases working, I checked the size of the old file - >> 17K. The new .bash_aliases is 2.5K with .bash_functions at 490B. > > In any case, the bash limits you quoted were concerned with the number > of definitions, not the size of the files containing them. > > Interesting that your aliases are on average as big as your functions. > About 90 of my aliases occupy 3.5k, whereas ~350 functions occupy 240k, > so averaging around 40 and 680 characters each, respectively. To clarify the file sizes. The original 17K was about 150 aliases plus 4 functions. The new aliases file at 2.5k is about 40 aliases plus several comments and blank lines. The finctions file is new yesterday and has 2 functions (one of them 2 short commands). I'll not likely get my functions much bigger - in the short term anyhow. > >> The errant function that failed after a little satisfactory use was to >> mount a USB and back it up to my system. It is used to run portable >> apps at a volunteer job - yes windows. I noticed that the sample >> functions on the web didn't have && for each line, so I removed them >> and performance is now back to what I expected. The errant line was >> the mount cmd. Originally if I had already mounted the USB, the >> function kept going. I don't recall adding the &&, so it didn't dawn >> on me to try removing them. (I worked around it by unmounting it (an >> alias) and trying the back-up again.) > > I don't follow what this is about, particularly each line having (or > not having) a &&. The only reason I raised this matter was that I had opened saying that my aliases were working. I originally thought that the function was my first sign of a problem My ERROR. It became as aside to the question of env variable limits 17Jun2024@18:47:29 > > Cheers, > David. > -- All the best Keith Bainbridge keithrbau@gmail.com keith.bainbridge.3216@gmail.com +61 (0)447 667 468 UTC + 10:00
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2024-06-17 11:20 +0200 |
| Message-ID | <IQgGR-3y99-3@gated-at.bofh.it> |
| In reply to | #270144 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Jun 17, 2024 at 06:47:41PM +1000, Keith Bainbridge wrote: > > On 17/6/24 14:20, David Wright wrote: > > Just some random thoughts: > > > > On Sun 16 Jun 2024 at 18:13:36 (+1000), Keith Bainbridge wrote: [...] > > All the aliases that lie textually after the one with the missing ' > > will remain undefined, so you can use bisection to locate where in > > the file problem lies. > > > If I didn't use a syntax matching editor this may have easily been my > problem. I'm still pretty convinced that you're looking at a syntax problem. Shell syntax is... not always trivial. I wouldn't trust most text editors 100% on that. One thing you might try is to run your file through "bash -n" which checks syntax without executing (well: it tries to: with languages like shell, this is actually practically impossible). Another thing would be to share your whole script here, but then you'll want to make sure that there's nothing in there you want to consider confidential. Cheers -- t
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | linux.debian.user
csiph-web