• two digit years must die

    From Maurice Kinal@2:280/464.113 to All on Thu Dec 17 17:39:29 2020
    -={ Geloofwaardige datetime-stempel voor Ladysmith BC, Canada: 2020-12-17 17:39:29 -0800 }=-

    Hallo All!

    After playing around with two digit years I've discovered that at the zero hour of January 1st 2069 coreutil's date application suddenly reverts back to 1969 as shown below;

    -={ date --date='31 Dec 68 23:59:59 +0000' +'%F %T %z' }=-
    2068-12-31 23:59:59 +0000

    -={ date --date='1 Jan 69 00:00:00 +0000' +'%F %T %z' }=-
    1969-01-01 00:00:00 +0000

    Note that I am using for input the FTN two digit year with a corrected UTC offset rather than the documented fts-4008 TZUTC flag which will produce an error for all eastern timezones using proper date and time applications no matter if two or four digit years. I am not aware of any routine that will properly compensate for this obvious flaw other than one I wrote specifically to address the FTSC's obvious handicap when it comes to recognizing reality and their part in the propagation of msg corruption. :::tsk, tsk:::

    Of further interest is the output of converting 2069 datetime stamps to unixtime will produce negative seconds that will be repeated in reverse in 2070 since everything up to 2099 reverts back to the 1900's as shown below;

    -={ date --date='1 Jan 69 00:00:01 +0000' +'%s' }=-
    -31535999

    -={ date --date='31 Dec 70 23:59:59 +0000' +'%s' }=-
    31535999

    Not good at all but not as bad as other examples of total two digit year corruption caused by other datetime apps as well as differing OSes and their associated problems with two digit years ... but I won't since they are really depressing to read about to say the least. Instead I will offer up that the corrected datetime stamp at the start of this message was calculated by the coreutils-8.32 date application as well as the FTN msgHeader's two digit year which is NEVER used again for anything. The proper solution would be to finally get rid of it which should have happened at least in 2002 when it was declared obsolete in use for digital communications. If it isn't obvious to you then I am guessing you're a member of the FTSC. :::snicker:::

    Het leven is goed,
    Maurice

    ... Gyf þu well sprece, wyrc æfter swa.
    If you speak well, act accordingly.
    --- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Fri Dec 18 08:01:00 2020
    Hello Maurice!

    ** On Thursday 17.12.20 - 17:39, Maurice Kinal wrote to All:

    After playing around with two digit years I've discovered
    that at the zero hour of January 1st 2069 coreutil's date
    application suddenly reverts back to 1969...

    Are you doing that on an 16-bit system?

    On a semi-related note, I found out that both of my iPods will
    be useless for date related things once 2038 rolls around. I
    may still keep them for playing music, podcasts and some
    videos - or maybe I'll expire before then! :/

    --
    ../|ug

    --- OpenXP 5.0.47
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Charles Pierson@1:106/127 to August Abolins on Fri Dec 18 13:31:39 2020
    On 18 Dec 2020, August Abolins said the following...
    On a semi-related note, I found out that both of my iPods will
    be useless for date related things once 2038 rolls around. I
    may still keep them for playing music, podcasts and some
    videos - or maybe I'll expire before then! :/


    Are all of these date issues BIOS related?

    --- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
    * Origin: theoasisbbs.ddns.net:1357 (1:106/127)
  • From Maurice Kinal@2:280/464.113 to August Abolins on Fri Dec 18 09:10:33 2020
    -={ Geloofwaardige datetime-stempel voor Ladysmith BC, Canada: 2020-12-18 09:10:33 -0800 }=-

    Hallo August!

    Are you doing that on an 16-bit system?

    Nope. It is a 64-bit system and coreutils date uses a 64-bit floating point instead of a 64-bit signed integer which will expire on Wed Dec 31 23:59:59 UTC 2147485547. That is well over 2 billion years from now.

    On a semi-related note, I found out that both of my iPods will
    be useless for date related things once 2038 rolls around.

    That is the usual 32-bit signed integer unixtime bug and has been well known for decades. Same with the ntp datetime except that expires sooner (2036) as the base year there is 1900 instead of 1970 which expains the earlier expiration date. Exact same problem though.

    I may still keep them for playing music, podcasts and some
    videos - or maybe I'll expire before then! :/

    It is entirely possible that I could make it until then. I am not betting on it though and I am not entirely sure I want to depending on my health.

    Anyhow both ntp and unix are moving to a 64-bit signed integer so this will be solved long before then if it hasn't already happened.

    However the issue I am pointing out has nothing to do with the 32-bit issue but instead is a product of the two digit year which has a very easy fix - don't EVER use a two digit year. It is a stupid idea that has been demonstrated since the late 1990's up to 2019 which is the last one I was aware of. I have run across a few reports that some windows apps have a 20 year cycle for this particular bug set to go off at the end of 2029. I could look it up again and give a reference if it matters any.

    Het leven is goed,
    Maurice

    ... Geþyld byþ middes eades.
    Patience is half of happiness.
    --- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Maurice Kinal@2:280/464.113 to Charles Pierson on Fri Dec 18 09:38:48 2020
    -={ Geloofwaardige datetime-stempel voor Ladysmith BC, Canada: 2020-12-18 09:38:48 -0800 }=-

    Hallo Charles!

    Are all of these date issues BIOS related?

    No. That is a different kettle of fish although in the case of a bios usually it can be flashed with a proper fix when needed. I believe that is the usual fix for many gps recievers that have the two digit year problem embedded in them, except they call it a firmware upgrade. Personally I think it is a ripoff.

    Het leven is goed,
    Maurice

    ... Sorg ond slæp somod ætgædre earmne anhogan oft gebindað.
    Sorrow and sleep both together often bind the wretched solitary person.
    --- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Denis Mosko@2:5064/54.1315 to Maurice Kinal on Mon Dec 21 17:38:14 2020
    Maurice!

    https://www.tickcounter.com/countdown/2342277/countdown-to-chinese-new-year

    Is it in January?

    --- GoldED+/W32-MINGW 1.1.5-b20120519 (Kubik 3.0)
    * Origin: ˆá¯®«ì§ã©â¥ ¯®á㤮¬®¥ç­ãî ¬ è¨­ã ¯à¨ full § £à㧪¥. (2:5064/54.1315)
  • From Maurice Kinal@2:280/464.113 to Denis Mosko on Mon Dec 21 09:20:08 2020
    -={ Geloofwaardige datetime-stempel voor Ladysmith BC, Canada: 2020-12-21 09:20:08 -0800 }=-

    Hallo Denis!

    Is it in January?

    Пт 12 фев 2021.

    Het leven is goed,
    Maurice

    ... Meotud ana wat hwær se cwealm cymeþ, þe heonon of cyþþe gewiteþ.
    Only God knows where plague goes when it departs from a place.
    --- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Denis Mosko@2:5064/54.1315 to Maurice Kinal on Mon Dec 21 22:24:40 2020
    Maurice!
    Žâ¢¥â ­  á®®¡é¥­¨¥ Maurice Kinal (2:280/464.113) ª Denis Mosko, ­ ¯¨á ­­®¥ 21 ¤¥ª 20 ¢ 09:20:
    DM>> Is it in January?
    MK> Пт 12 фев 2021.
    Is it Vtor 12 Janvar 2021,
    Maurice?

    --- GoldED+/W32-MINGW 1.1.5-b20120519 (Kubik 3.0)
    * Origin: ˆá¯®«ì§ã©â¥ ¯®á㤮¬®¥ç­ãî ¬ è¨­ã ¯à¨ full § £à㧪¥. (2:5064/54.1315)
  • From Maurice Kinal@2:280/464.113 to Denis Mosko on Mon Dec 21 11:57:26 2020
    -={ Geloofwaardige datetime-stempel voor Ladysmith BC, Canada: 2020-12-21 11:57:26 -0800 }=-

    Hallo Denis!

    Is it Vtor 12 Janvar 2021,

    Febuary. I am not sure what it would be in ascii russian characters so we'll have to settle for english ... for now. In the corrected form (numeric) it would be 2021-02-12. I think that format is the best.

    Het leven is goed,
    Maurice

    ... Ear byþ egle eorla gehwylcun.
    The grave is a horror to every man.
    --- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Anton Mikhaylov@1:275/98 to Maurice Kinal on Tue Dec 22 08:51:02 2020
    Hi Maurice,

    Febuary. I am not sure what it would be in ascii russian characters so we'll have to settle for english ... for now. In the corrected form (numeric) it would be 2021-02-12. I think that format is the best.

    YYYY-MM-DD is the best format to read, store and sort (!) dates in strings, IMHO.

    > Anton Mikhaylov AKA twix <

    --- Mystic BBS v1.12 A42 2019/02/01 (Linux/64)
    * Origin: twixed BBS (1:275/98)
  • From Maurice Kinal@2:280/464.113 to Anton Mikhaylov on Tue Dec 22 07:09:45 2020
    -={ Geloofwaardige datetime-stempel voor Ladysmith BC, Canada: 2020-12-22 07:09:45 -0800 }=-

    Hallo Anton!

    YYYY-MM-DD is the best format to read, store and sort (!) dates
    in strings, IMHO.

    I couldn't agree more but would like to add to the above that they are far more universally accepted and understood than any other datetime format for both computers and humans.

    Het leven is goed,
    Maurice

    ... Wes þu þinum yldrum arfæst symle, fægerwyrde.
    Be respectful to your elders always, speaking fair words.
    --- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Charles Pierson@1:229/426.67 to Maurice Kinal on Fri Jan 8 10:23:22 2021
    Hello, Maurice Kinal.
    On 12/21/20 11:57 AM you wrote:

    -={ Geloofwaardige datetime-stempel voor Ladysmith BC, Canada:
    2020-12-21 11:57:26 -0800 }=- Hallo Denis!
    Is it Vtor 12 Janvar 2021,
    Febuary. I am not sure what it would be in ascii russian
    characters so we'll have to settle for english ... for now. In
    the corrected form (numeric) it would be 2021-02-12. I think that
    format is the best.

    Interesting. That also happens to be my wife's birthday.


    --
    Best regards!
    Posted using Hotdoged on Android
    --- Hotdoged/2.13.5/Android
    * Origin: Houston, TX (1:229/426.67)
  • From Maurice Kinal@1:153/7001 to Charles Pierson on Fri Jan 8 17:30:00 2021
    -={ 2021-01-08 17:30:00.380500458+00:00 }=-

    Hey Charles!

    Interesting. That also happens to be my wife's birthday.

    This time around it happens to be the year of the Ox. Does that also jive with her?

    Not that it matters any but I happen to be a Horse whose birthday isn't anywhere near Chinese New Year. Also I am not Chinese.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Charles Pierson@1:106/127 to Maurice Kinal on Fri Jan 8 11:45:25 2021
    On 08 Jan 2021, Maurice Kinal said the following...
    Interesting. That also happens to be my wife's birthday.

    This time around it happens to be the year of the Ox. Does that also
    jive with
    her?

    I like living too much to say that about her.

    --- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
    * Origin: theoasisbbs.ddns.net:1357 (1:106/127)
  • From Maurice Kinal@1:153/7001 to Charles Pierson on Fri Jan 8 18:02:59 2021
    -={ 2021-01-08 18:02:59.468818076+00:00 }=-

    Hey Charles!

    I like living too much to say that about her.

    :-) Understood but that isn't really what was intended. I was just wondering if the coincidence happen to jive with her birthday year given that Chinese New Year doesn't usually fall on Feb 12th. For instance next year it is Feb 1st.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Denis Mosko@2:5064/54.1315 to All on Sun Jan 10 14:11:14 2021
    "Job with newspaper 'METRO' at 7 o'clock (subway hall) 5/2.

    You can goto home at 11 o'clock."

    ... Is it really?
    --- GoldED+/W32-MINGW 1.1.5-b20120519 (Kubik 3.0)
    * Origin: ˆé¨ ª®«ïáªã, ¯à®¢¥à¨¬, ¯à¨«¥â¥«¨ «¨ ¯â¨çª¨, ­  ª®à¬ (2:5064/54.1315)