1. Forum
  2. FidoNet
  3. MAKENL NG

  • Feature request

    From Michiel van der Vlist@2:280/5555 to All on Sun Jun 19 10:28:55 2022

    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)
  • From Nick Andre@1:229/426 to Michiel Van Der Vlist on Sun Jun 19 07:15:49 2022
    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)
  • From Ward Dossche@2:292/854 to Michiel van der Vlist on Sun Jun 19 16:00:26 2022
    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)
  • From Michiel van der Vlist@2:280/5555 to Ward Dossche on Sun Jun 19 16:08:34 2022
    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)
  • From Ward Dossche@2:292/854 to Michiel van der Vlist on Mon Jun 20 22:13:11 2022
    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)