* Originally in NETMAIL001
* Crossposted in MAKENL_NG

Hello Andrew,

I request that the following option be added to Makenl:

RemoveBOM 1

What should it do?

Remove any UTF-8 Byte Order Mark (BOM).


Why?

Now that a project has started with a daily nodelist in UTF-8 in Z2, nodelist clercks need a simple way to edit UTF-8 text files. Some UTF-8 capable editors insist on adding a BOM to the edited file. Adding a BOM to an UTF-8 file is an outdated concept, but some editors, notably, Notepad, insist on adding one anyway. For most applications this does no harm, so people are not inclined to dump their favorite editor in favour of one that does not insist on adding a BOM. For nodelist processing this is a show stopper. A BOM interferes with nodelist processing. There should be no BOM in the nodelist. Forcing nodelist clercks to change editors or jump through some other hoops just to get rid of a BOM raises a threshold that may stop them from participating in the project. If MakeNl had the ability to remove BOMs, they could continue to use their favorite editor without having to worry about BOMs.


Notes:

Normally a BOM would only be found at the start of a file, but some nodelist clercks use scripts that concatenate files, so a BOM might also appear in the middle of a file. It may even be found in the middle of a line.

The UTF-8 BOM consists of the three bytes 0xEF 0xBB 0xBF. Whenever this sequence appears it should be removed.


Cheers, Michiel




--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

I request that the following option be added to Makenl:

RemoveBOM 1

What should it do?

Remove any UTF-8 Byte Order Mark (BOM).

I second the motion.

\%/@rd

--- D'Bridge 3.99
* Origin: Many Glacier -- Protect - Preserve - Conserve (2:292/854)

Hello Ward!

20 Feb 15 22:09, you wrote to Andrew Leary:

I request that the following option be added to Makenl:
RemoveBOM 1
What should it do?
Remove any UTF-8 Byte Order Mark (BOM).

I second the motion.

You could implement that in ERRFLAGS.

I don't care, I remove the BOM in a preprocessor, but having it internal
in makenl will serve a good purpose.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hi,

On 2015-02-20 21:58:12, Michiel van der Vlist wrote to Andrew Leary:
about: "Feature request":

MvdV> I request that the following option be added to Makenl:

MvdV> RemoveBOM 1

MvdV> What should it do?

MvdV> Remove any UTF-8 Byte Order Mark (BOM).

Why should it be an option? Is there a situation where you want to keep the BOM?

Bye, Wilfred.


--- FMail-W32-1.69.1.95-B20140716
* Origin: Native IPv6 connectable node (2:280/464)

Hello Wilfred,

On Friday February 20 2015 23:07, you wrote to me:

MvdV>> Remove any UTF-8 Byte Order Mark (BOM).

Why should it be an option? Is there a situation where you want to
keep the BOM?

I didn't consider that. No, I can't think of a reason why I'd want to keep a BOM.

However... Predicting the future is not one of my strong points. A good reason may come up some day. I prefer not to close down options too soon. Right now, now that we have an active developer it is little extra work to make it an option. The code for generating options is there. It will just be another if/then in the code.

In five years the situation may be different and making it an option then may be a lot harder.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hi,

On 2015-02-21 15:19:09, Michiel van der Vlist wrote to Wilfred van Velzen:
about: "Feature request":

MvdV>>> Remove any UTF-8 Byte Order Mark (BOM).

Why should it be an option? Is there a situation where you want to
keep the BOM?

MvdV> I didn't consider that. No, I can't think of a reason why I'd want to keep
MvdV> a BOM.

MvdV> However... Predicting the future is not one of my strong points. A good
MvdV> reason may come up some day. I prefer not to close down options too soon.
MvdV> Right now, now that we have an active developer it is little extra work to
MvdV> make it an option. The code for generating options is there. It will just
MvdV> be another if/then in the code.

Maybe you want to have a BOM as the first few bytes of the produced nodelist by
makenl (or not), so that could be an option. But keeping them in the middle of the file breaks the standard, so I can't imagine why that would be usefull, even in the future. But it's up to the developper. ;)

Bye, Wilfred.


--- FMail-W32-1.69.1.95-B20140716
* Origin: Native IPv6 connectable node (2:280/464)

On Fri, 20 Feb 2015, Wilfred van Velzen wrote to Michiel van der Vlist:

MvdV> I request that the following option be added to Makenl:

MvdV> RemoveBOM 1

MvdV> What should it do?

MvdV> Remove any UTF-8 Byte Order Mark (BOM).

Why should it be an option? Is there a situation where you want to
keep the BOM?

what would happen on big endian machines if they tried to compile a UTF-8 nodelist without a BOM in it? perhaps something is being missed in this thinking and request to remove the BOM? granted, we're talking about UTF-8 and not UTF-16 or UTF-32 where it might matter... after some bit of time, yeah, i think i can agree with the request, too...

)\/(ark


* Origin: (1:3634/12)

Hello Wilfred!

21 Feb 15 15:54, you wrote to Michiel van der Vlist:

Maybe you want to have a BOM as the first few bytes of the produced nodelist by makenl (or not), so that could be an option. But keeping them in the middle of the file breaks the standard, so I can't imagine why that would be usefull, even in the future. But it's up to the developper. ;)

For browsing the nodelist, the position of the BOM when used, should be the
first three bytes in the file. That however breaks makenl. The danger of
BOM creeping in is mainly at the start of the included files.
Another place where de BOM may cause havoc is with manually maintained
segments without the headerline. That will probably cause makenl to mark
the line with the segment host as in error, unless the BOM is directly followed by cr/lf.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hi,

On 2015-02-21 09:50:03, mark lewis wrote to Wilfred van Velzen:
about: "Feature request":

MvdV>> I request that the following option be added to Makenl:

MvdV>> RemoveBOM 1

MvdV>> What should it do?

MvdV>> Remove any UTF-8 Byte Order Mark (BOM).

Why should it be an option? Is there a situation where you want to
keep the BOM?

what would happen on big endian machines if they tried to compile a UTF-8 nodelist without a BOM in it? perhaps something is being missed in this thinking and request to remove the BOM? granted, we're talking about UTF-8 and not UTF-16 or UTF-32 where it might matter... after some bit of time, yeah, i think i can agree with the request, too...

The proposed option is about removing BOMs from the imput files. So the generated nodelist, doesn't contain a number of BOMS in the middle of it.

Whether or not the generated nodelist, should contain a BOM on the front of the
file is a different matter, and this could be a usefull option in makenl.

Bye, Wilfred.


--- FMail-W32-1.69.1.95-B20140716
* Origin: Native IPv6 connectable node (2:280/464)

Hi,

On 2015-02-21 16:09:08, Kees van Eeten wrote to Wilfred van Velzen:
about: "Feature request":

Maybe you want to have a BOM as the first few bytes of the produced
nodelist by makenl (or not), so that could be an option. But keeping
them in the middle of the file breaks the standard, so I can't
imagine why that would be usefull, even in the future. But it's up to
the developper. ;)

For browsing the nodelist, the position of the BOM when used, should
be the first three bytes in the file. That however breaks makenl. The danger of BOM creeping in is mainly at the start of the included
files. Another place where de BOM may cause havoc is with manually maintained segments without the headerline. That will probably cause makenl to mark the line with the segment host as in error, unless the
BOM is directly followed by cr/lf.

So what you are saying is that BOMs should always be filtered out from input files before further processing. And there's no need to make this an option. ;)

Bye, Wilfred.


--- FMail-W32-1.69.1.95-B20140716
* Origin: Native IPv6 connectable node (2:280/464)

* Originally in NETMAIL001
* Crossposted in MAKENL_NG

Hello Andrew,

I request that the following option be added to Makenl:

RemoveBOM 1

What should it do?

Remove any UTF-8 Byte Order Mark (BOM).

Why?

Now that a project has started with a daily nodelist in UTF-8 in Z2, nodelist clercks need a simple way to edit UTF-8 text files. Some UTF-8 capable editors insist on adding a BOM to the edited file. Adding a BOM to an UTF-8 file is an outdated concept, but some editors, notably, Notepad, insist on adding one anyway. For most applications this does no harm, so people are not inclined to dump their favorite editor in favour of one that does not insist on adding a BOM. For nodelist processing this is a show stopper. A BOM interferes with nodelist processing. There should be no BOM in the nodelist. Forcing nodelist clercks to change editors or jump through some other hoops just to get rid of a BOM raises a threshold that may stop them from participating in the project. If MakeNl had the ability to remove BOMs, they could continue to use their favorite editor without having to worry about BOMs.

Notes:

Normally a BOM would only be found at the start of a file, but some nodelist clercks use scripts that concatenate files, so a BOM might also appear in the middle of a file. It may even be found in the middle of a line.

The UTF-8 BOM consists of the three bytes 0xEF 0xBB 0xBF. Whenever this sequence appears it should be removed.

Cheers, Michiel

I will see what I can do on this. It will probably require some changes in how
the input lines are parsed, so I expect it will not be done until 3.5.0 at the earliest.

Regards,

Andrew

--- AfterShock/Android 1.6
* Origin: Bits & Bytes Droid (1:320/119.2)

Hello Kees,

On Saturday February 21 2015 16:09, you wrote to Wilfred van Velzen:

For browsing the nodelist, the position of the BOM when used, should
be the first three bytes in the file. That however breaks makenl. The danger of BOM creeping in is mainly at the start of the included
files.

If a prolog or epilog file is created without a ;X at the beginning of each line, Makenl will add ";S " to the beginning of lines not already starting with
a comment indicator. If the file to be included has a BOM, it will appear in the 4th position of the first line of the prolog or epilog.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hello mark,

On Saturday February 21 2015 09:50, you wrote to Wilfred van Velzen:

what would happen on big endian machines if they tried to compile a
UTF-8 nodelist without a BOM in it?

Nothing. In UTF-8 byte order does not apply. The BOM is reduced to a unique byte sequence that marks a file as encoded in UTF-8.

granted, we're talking about UTF-8 and not UTF-16 or UTF-32 where it
might matter...

Exactly.

after some bit of time, yeah, i think i can agree with the request,
too...

Nice.. ;-)


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hello Wilfred!

21 Feb 15 16:47, you wrote to me:

So what you are saying is that BOMs should always be filtered out from input files before further processing. And there's no need to make this an option. ;)

From what I have seen and read, the BOM is used as a marker for Notepad to
switch to UTF-8 when the file is openend. When a file is saved as a UTF-8
file the BOM is put into the first 2 positions of the file.

I will have to guess how administrators prepare their submissions to make
a guess where the BOM can be introduced. If nobody uses Notepad for
editing parts of their submissions the problem is probably moot.

So how do people maintain their segments and what files are there.

Lets start with the three text files. When edited, the may have a BOM at
their start and that BOM will end up in the middle of a comment section.
It shows as 3chars of rubbish.

Some maintain their section is the "data" section of the control file.
In that case the *.ctl will start with a BOM, makenl may throw an error
messages, and continue as usual.

Some may include subsegments in the files section of the CTL.
The included files will often be generated with makenl by a lower oder admin.
One can expect the file to be save and without a BOM.
Some submit manually maintained segments, those files are a hazard anyway
and should be checked and cleaned anyway. There could be a BOM at their start.

A last where a segment can be maintained in an editor is the segment file
in the master directory. There a BOM will be placed at the start of the
file, i.e. at the start of the headerline. As far as I know the old
headerline is ignored when makenl processes the modified segment in the
master directory.

In short the only usefull place for the BOM would be the start of the file.
That line is generated by makenl without a BOM. Remnants of BOM's is
other files could show up in comment sections, as 3char rubbish, with no
function. So there is no place for the BOM in de nodelist and leaving it
in as an option is useless.

The nodelist is a byte ordered file, so there is no endian dependency.
Whoever want to use it in a word ordered way, will have to redesign
makenl anyway.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Andrew,

On Saturday February 21 2015 11:32, you wrote to me:

The UTF-8 BOM consists of the three bytes 0xEF 0xBB 0xBF.
Whenever this sequence appears it should be removed.

I will see what I can do on this. It will probably require some
changes in how the input lines are parsed, so I expect it will not be
done until 3.5.0 at the earliest.

Wouldn't it be simpler to do it when writing to the output?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hello Kees,

On Saturday February 21 2015 17:06, you wrote to Wilfred van Velzen:

From what I have seen and read, the BOM is used as a marker for
Notepad to switch to UTF-8 when the file is openend.

It will switch to UTF-8 mode if the first non ASCII character it sees is encoded in UTF-8. This could be the BOM or any other UTF-8 encoded character.

When a file is saved as a UTF-8 file the BOM is put into the first 2 positions of the file.

The first three bytes.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hello Michiel!

21 Feb 15 17:56, you wrote to me:

When a file is saved as a UTF-8 file the BOM is put into the first 2
positions of the file.

MvdV> The first three bytes.

Yes, ofcourse.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Andrew,

Saturday February 21 2015 17:53, I wrote to you:

The UTF-8 BOM consists of the three bytes 0xEF 0xBB 0xBF.
Whenever this sequence appears it should be removed.

I will see what I can do on this. It will probably require some
changes in how the input lines are parsed, so I expect it will
not be done until 3.5.0 at the earliest.

Wouldn't it be simpler to do it when writing to the output?

Eh... drop that. I wasn't thinking. It should indeed be done when reading the input, otherwise MakeNl will not parse the input when a BOM is present.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

On Sat, 21 Feb 2015, Wilfred van Velzen wrote to mark lewis:

MvdV>> I request that the following option be added to Makenl:

MvdV>> RemoveBOM 1

MvdV>> What should it do?

MvdV>> Remove any UTF-8 Byte Order Mark (BOM).

Why should it be an option? Is there a situation where you want to
keep the BOM?

what would happen on big endian machines if they tried to compile
a UTF-8 nodelist without a BOM in it? perhaps something is being
missed in this thinking and request to remove the BOM? granted,
we're talking about UTF-8 and not UTF-16 or UTF-32 where it might matter... after some bit of time, yeah, i think i can agree with
the request, too...

The proposed option is about removing BOMs from the imput files.

yes, i understand this...

So the generated nodelist, doesn't contain a number of BOMS in
the middle of it.

this i didn't quite understand... i'm not sure how one can assemble a segment by simply concatenating files together... the CRC would not be right if it exists at all...

Whether or not the generated nodelist, should contain a BOM on
the front of the file is a different matter, and this could be a
usefull option in makenl.

i view it as all the same... individual segments are made in the same manner as
the full nodelist... as i said, after thinking about it, removing the BOMs from
the input files is ok by me... there definitely should not be any in the rest of the document and certainly not in the middle of some line(s)... granted, the
UTF-8 specs state that BOMs in the middle of the lines are to be treated in a specific manner which would basically render them invisible but still they shouldn't be anywhere except at the beginning of a document :shrug:

)\/(ark


* Origin: (1:3634/12)

Hi,

On 2015-02-21 14:56:20, mark lewis wrote to Wilfred van Velzen:
about: "Feature request":

The proposed option is about removing BOMs from the imput files.

yes, i understand this...

Good. ;)

So the generated nodelist, doesn't contain a number of BOMS in
the middle of it.

this i didn't quite understand... i'm not sure how one can assemble a segment by simply concatenating files together... the CRC would not be right if it exists at all...

It's more of a problem for the text files that are also used to create the nodelist, like the epilog and prolog. If they are not stripped from those, you get BOM's in de comment sections, this is not how it should be, but probably doesn't hurt the nodelist processing.

As Kees also explained it would probably create all kinds of problems if they are in the segment files the nodelist is created from, so that's where you are right also, that problems with the CRC could arrise...


Bye, Wilfred.


--- FMail-W32-1.69.1.95-B20140716
* Origin: Native IPv6 connectable node (2:280/464)

Hello All,

In order to make it easier for nodelist clerks to synchronise their efforts across time zones, I suggest the following;


UseUTC (0/1) (default 0)


This instructs MakeNl to use UTC instead of local time to determine the day of the week and other time related issues.

E.G. When it is Thursday 21:00 local time and it is Friday 01:00 UTC, Makenl will act as if is is run on Friday and use the day of the week number corresponding to Friday.


In some cases, it may be necessary to override the OS's and/or compiler's time functions. So I suggest the following option:


UseTZUTC (0/1) (default 0)

Use the TZUTC environment variable to derive UTC from local time, instead of using the value supplied by the OS and/or the compiler's library functions.


Cheers, Michiel


---
* Origin: http://www.vlist.eu (2:280/5555)

Hello Michiel!

01 Mar 17 16:49, you wrote to all:

In order to make it easier for nodelist clerks to synchronise their efforts across time zones, I suggest the following;

UseUTC (0/1) (default 0)

This instructs MakeNl to use UTC instead of local time to determine
the day of the week and other time related issues.

E.G. When it is Thursday 21:00 local time and it is Friday 01:00 UTC, Makenl will act as if is is run on Friday and use the day of the week number corresponding to Friday.

In some cases, it may be necessary to override the OS's and/or
compiler's time functions. So I suggest the following option:

UseTZUTC (0/1) (default 0)

Use the TZUTC environment variable to derive UTC from local time,
instead of using the value supplied by the OS and/or the compiler's library functions.

Your feature request is noted. This will take some time to code and test, so I can make no promises as to when it will be available.

Andrew

--- GoldED+/LNX 1.1.5-b20161221
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Andrew,

On Wednesday March 01 2017 12:34, you wrote to me:

In order to make it easier for nodelist clerks to synchronise
their efforts across time zones, I suggest the following;

UseUTC (0/1) (default 0)

[..]

Your feature request is noted.

Thank you. :-)

This will take some time to code and test, so I can make no promises
as to when it will be available.

No problem. Take your time, I can be patient.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hello Michiel!

01 Mar 17 16:49, you wrote to All:

MvdV> In order to make it easier for nodelist clerks to synchronise their
MvdV> efforts across time zones, I suggest the following;


MvdV> UseUTC (0/1) (default 0)


MvdV> This instructs MakeNl to use UTC instead of local time to determine the
MvdV> day of the week and other time related issues.

MvdV> E.G. When it is Thursday 21:00 local time and it is Friday 01:00 UTC,
MvdV> Makenl will act as if is is run on Friday and use the day of the week
MvdV> number corresponding to Friday.


MvdV> In some cases, it may be necessary to override the OS's and/or
MvdV> compiler's time functions. So I suggest the following option:


MvdV> UseTZUTC (0/1) (default 0)

MvdV> Use the TZUTC environment variable to derive UTC from local time,
MvdV> instead of using the value supplied by the OS and/or the compiler's
MvdV> library functions.

Why would you make it so intricate. As far as I know it gouverned by
PublishDay

If you run before the day has stated, you set Publishday to the nextday,
otherwise to the current day.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Michiel!

Wednesday March 01 2017 16:49, you wrote to All:

Hello All,

In order to make it easier for nodelist clerks to synchronise their
efforts across time zones, I suggest the following;

UseUTC (0/1) (default 0)

This instructs MakeNl to use UTC instead of local time to determine
the day of the week and other time related issues.

E.G. When it is Thursday 21:00 local time and it is Friday 01:00 UTC,
Makenl will act as if is is run on Friday and use the day of the week
number corresponding to Friday.

In some cases, it may be necessary to override the OS's and/or
compiler's time functions. So I suggest the following option:

UseTZUTC (0/1) (default 0)

Use the TZUTC environment variable to derive UTC from local time,
instead of using the value supplied by the OS and/or the compiler's
library functions.

As I run multi-user systems (Linux) I cannot change the time at a system level.

So a setting within makenl to deal would be better.

There again just adjust your time set for sending to the earliest period for both time changes, e.g., forward setting.



Vince

--- Mageia Linux v5/Mbse v1.0.6.14/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Michiel,

In order to make it easier for nodelist clerks to synchronise their
efforts across time zones, I suggest the following;

UseUTC (0/1) (default 0)

UseTZUTC (0/1) (default 0)

Is there really a need for this or are you getting bored?

To me it seems a lot of work for Andrew Leary for a fad that in all likelihood will be used by no-one.

\%/@rd

--- D'Bridge 3.99
* Origin: Many Glacier -- Protect - Preserve - Conserve (2:292/854)

Hi Ward,

In order to make it easier for nodelist clerks to synchronise their
efforts across time zones, I suggest the following;

UseUTC (0/1) (default 0)

UseTZUTC (0/1) (default 0)

Is there really a need for this or are you getting bored?

To me it seems a lot of work for Andrew Leary for a fad that in all likelihood
will be used by no-one.

I also don't see a real use for this...

Take care,
Janis

--- BBBS/Li6 v4.10 Toy-3
* Origin: Prism bbs (1:261/38)

Hello Michiel!

01 Mar 2017 16:49, Michiel van der Vlist wrote to All:

MvdV> Use the TZUTC environment variable to derive UTC from local time,
MvdV> instead of using the value supplied by the OS and/or the compiler's
MvdV> library functions.

so its no need if its supported, it would just be good to see it dokumented not
make work arounds for badly docs

locale LC_TIME

with here gives

----- LC_TIME begins -----
s°n;man;tir;ons;tor;fre;l°r
s°ndag;mandag;tirsdag;onsdag;torsdag;fredag;l°rdag jan;feb;mar;apr;maj;jun;jul;aug;sep;okt;nov;dec januar;februar;marts;april;maj;juni;juli;august;september;oktober;november;december
;
%a %d %b %Y %T %Z
%d-%m-%Y
%T







0
s
7
19971130
4
2
2
1

%a %b %e %H:%M:%S %Z %Y
ISO-8859-1
----- LC_TIME ends -----

if makenl support it its open to make it more localy

but yes your point is more that UTC should be more considered, not how cron are
runned based on locale, so its not really a makenl feature request, more how to
make it in local crontabs :)


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.11.2-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

In order to make it easier for nodelist clerks to synchronise their efforts across time zones, I suggest the following;


UseUTC (0/1) (default 0)


This instructs MakeNl to use UTC instead of local time to determine the day of the week and other time related issues.

E.G. When it is Thursday 21:00 local time and it is Friday 01:00 UTC, Makenl will act as if is is run on Friday and use the day number corresponding to Friday.


In some cases, it may be necessary to override the OS's and/or compiler's time functions. So I suggest the following option:


UseTZUTC (0/1) (default 0)

Use the TZUTC environment variable to derive UTC from local time, instead of using the value supplied by the OS and/or the compiler's library functions.


--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

On 19 Jun 22 10:28:55, Michiel Van Der Vlist said the following to All:

In order to make it easier for nodelist clerks to synchronise their efforts across time zones, I suggest the following;

HAHAHAHAAHAHAHAHAHAHAAH

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Michiel,

In order to make it easier for nodelist clerks to synchronise their
efforts across time zones, I suggest the following;

Really?

I don't see how this (old) proposal is going to change anything. I also don't understand what needs to be synchronized at all. There will always be a 7hr delay for Z1-data in Z2, plus every ZC to my knowledge uses the latest zone-segments available ... there's no way on improving on that.

\%/@rd

--- DB4 - 20220519
* Origin: May the Source be with you (2:292/854)

Hello Ward,

On Sunday June 19 2022 16:00, you wrote to me:

In order to make it easier for nodelist clerks to synchronise
their efforts across time zones, I suggest the following;

Really?

I don't see how this (old) proposal is going to change anything. I
also don't understand what needs to be synchronized at all. There will always be a 7hr delay for Z1-data in Z2, plus every ZC to my knowledge uses the latest zone-segments available ... there's no way on
improving on that.

A quote from another area that you apparently do not read:

=== start quote ===

By virtue of geography, Z1 nodelists for a given julian day
are produced a few hours after the Z2 nodelist for that day.

4) It need not be. There is no formal rule that ZCs MUST issue "their" nodelist at or
shortly after 00:00 local time.

5) If the ZCs would coordinate and synchronise their efforts there need not be delays.
For example ZCs could agree to issue nodelists at 00:15 UTC. The ZCs could agree to
exchange zone segments with each other between 23:45 and 00:00 UTC. Segments submitted
by RCs before 23:30 UTC would be guaranteed to make it into the next nodelist. With Fido over IP there is no need for the old system of exchanging zone segments on
Wednesday to make it into Friday's nodelist. With nodelist segments being transfered in
seconds at virtually no cost, there is no need for such delays.

=== end quote ===

Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Michiel,

A quote from another area that you apparently do not read:

I am open and available for a lot of things.

If you would like to shove something over my desk, you know the procedure.

Take care,

\%/@rd

--- DB4 - 20220519
* Origin: May the Source be with you (2:292/854)