Subj : Re: conversion between lossless codecs
To   : August Abolins
From : Rob Swindell
Date : Mon Jan 03 2022 05:55 pm

  Re: Re: conversion between lossless codecs
  By: August Abolins to All on Mon Jan 03 2022 11:50 am

 >
 > >==================================================================<
 >  ** Original area               : "/FIDO/AUDIO"
 >  ** Original message from       : Wilfred van Velzen@2:280/464
 >  ** Original message to         : August Abolins
 >  ** Original date/time          : 03 Jan 22, 10:50
 > >==================================================================<
 >
 > Hi August,
 >
 > On 2022-01-02 18:59:00, you wrote to me:
 >
 >  AA>>> ..I have at least 2 other XP pcs, and
 >  AA>>> two Win7 pcs as alternatives.
 >
 >  WvV>> They will all break down in X years! ;-)
 >
 >  AA> You misremember. It's X+6 for 2038. The 2038 issue may indeed
 >  AA> be a little niggly issue.  :(
 >
 > X was supposed to be randomish number, not necessarily the roman numeral for
 > 10 ! ;-)
 >
 > But indeed 2038 is a real problem for fidonet...
 >
 > Bye, Wilfred.
 >
 > -+- FMail-lnx64 2.1.0.18-B20170815
 >  + Origin: FMail development HQ (2:280/464)
 >
 > ===
 >
 > Now.. THAT might be an interesting thing to talk about here.
 > What systems and processes are likely to fail amidst the 2038
 > deadline, and what hope is there for continued FTN operations?

I don't think anything in the FidoNet specs requires a 32-bit time_t value. So 
while a lot FidoNet-era software may break in 2038, it's not really *because* 
they're FidoNet-related.

 > Is anyone working on converting necessary programs to 64bit?

I have been converting my use of signed 32-bit time_t's to unsigned 32-bit 
time_t's (good until the year 2105) and non-time_t-based date/time storage 
(e.g. ISO-8601 as strings or separate of long ints for date and time).

 > My understanding is that 2038-matter would affect 32-bit progs
 > and pcs.  That means, my XP machines (and possibly my Win7-
 > 32bit machines) will be non-functional especially for an app
 > that requires a proper date?

Not exactly. There are 64-bit time_t's available in the C runtime libraries for 
applications built for 32-bit OSes (e.g. Windows XP). Just because the OS is 
32-bit doesn't mean that the time_t value has to be 32-bit. The developer often 
must "opt-in" to specify the use of 64-bit time_t's in their application, but 
it is an option available to them.

The other option available to developers is to store unsigned 32-bit integers 
to represent the least significant 32-bits of 64-bit time_t values. This does 
limit the range of the time_t to a lowest/oldest date of Jan-1-1970/UTC, but it 
extends the largest/future date to some time in 2105 without impacting the 
number of bits/bytes required to store date/time values.
-- 
                                            digital man (rob)

This Is Spinal Tap quote #1:
Nigel Tufnel: These go to eleven.
Norco, CA WX: 54.2øF, 55.0% humidity, 2 mph NE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.14-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.