@MSGID: 5c3bf478
This entire msg, including FTN datetime, to, from and subject fields
with null terminators, was created with bash's printf builtin
function. No editor was harmed in the making of it.
Hi Maurice,
On 2019-01-14 02:31:20, you wrote to mark lewis:
@MSGID: 5c3bf478
This entire msg, including FTN datetime, to, from and subject fields with null terminators, was created with bash's printf builtin
function. No editor was harmed in the making of it.
Then it should be easy to add a CHRS, TZUTC, PID and TID kludge! ;)
This entire msg, including FTN datetime, to, from and subjectfields
with null terminators, was created with bash's printf builtin
function. No editor was harmed in the making of it.
Then it should be easy to add a CHRS, TZUTC, PID and TID kludge! ;)
Shouldn't the "tosser" be one to add its TID?
Then it should be easy to add a CHRS, TZUTC, PID and TID kludge
Het leven is goed,
... Huil niet om mij, ik heb vi.
Kludges are only there to cover deficiencies.
In het Brabantse land.
Geef mij maar een bord balkenbrij.
One thing for sure is that they don't solve anything and more often create more deficiencies. The lack of a '+' character for offsets east of prime meridian is a case in point as well as the so-called level in the CHRS kludge. However I do see a need for identification of the 8 bit character sets although I wish the FTSC would have used proper aliases as given by those who own them. LATIN1 is a very good example.
In het Brabantse land.
They stole my line!!! Tsk, tsk. I did see somewhere that someone unsuccessfully tried to sue over palagerism.
Your loss. It remains the best editor ever created, although when I first encountered vi I absolutely hated it. That was a very long time ago in a land far, far away.
Any way, they are the first two lines of a Dutch song.
This is Balkenbrij
in the times of the KMS-toolkit itr was probably the Korn-shell
Then it should be easy to add a CHRS, TZUTC, PID and TID kludge
@MSGID: 2:280/464.113 5c3cf22e
@REPLY: 2:280/464 5c3c4288
@CHRS: UTF-8 4
Halo Wilfred!
Then it should be easy to add a CHRS, TZUTC, PID and TID kludge
Two out of four kludges with this new-ish one out of three machines. Here is some text to make it accurate; A Møøse once bit my sister.
I think you meant 'Hallo'.
Hallo Wilfred!
I think you meant 'Hallo'.
Check the tearline for "MSGID: 2:280/464.113 5c3cf22e". On that machine the default language for the bash script is Spanish, whereas on this machine it is Dutch;
So shouldn't it have been 'Hola' instead of 'Halo' ? ;)
So shouldn't it have been 'Hola' instead of 'Halo' ? ;)
Hola Wilfred!
So shouldn't it have been 'Hola' instead of 'Halo' ? ;)
It is now. Thank you again for pointing it out.
Still in the middle of the upgrade of aarch64-raspi3b+-linux-gnu but
the next certified Møøse MSG should reflect the change in the
tearline. I thought I'd better take care of this while it is still
fresh in my mind. Getting older and stupider is my excuse. :::sigh:::
La vida es buena,
Maurice
... No llores por mi tengo vi.
Hey mark!
This entire msg, including FTN datetime, to, from and subject fields with null terminators, was created with bash's printf builtin function. No editor was harmed in the making of it.
The obsolete FTN DateTime stamp in the MSG header is UTC as it should beso
a TZUTC doesn't add anything of consequence, especially one that isn't compliant to accepted worldwide standards for a timezone offset.
systems that display the message's written time in local time or
UTC if configured to do so
you cannot convert to/from local/UTC if the TZ isn't known
systems that display the message's written time in local time or UTC
if configured to do so
I've yet to see any BBS get that right if indeed the BBS software can
be configured to do so.
Do you have or know of a working example that indeed gets it right?
you cannot convert to/from local/UTC if the TZ isn't known
Understood. Speaking for myself, I have never bothered and don't use the FTN datetime for anything, nevermind converting it even if only display purposes. What I was taught AGES ago is the data is the data even when it is obviously wrong, and that to tamper with raw data is EXTREMELY vorbotten.
If I cared, for local display I would do something like this (using
the datetime and TZUTC from "MSGID: 1:3634/12.73 5c3e3137");
i think Synchronet BBS does but i haven't looked very closely to
see for sure
we're not tampering with anything
it is a simple thing to do if all the necessary parts are
available...
$(date +%j)
| Sysop: | Rempala |
|---|---|
| Location: | Richlands, NC |
| Users: | 103 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 242:17:29 |
| Calls: | 158 |
| Files: | 6 |
| Messages: | 110,659 |