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)