I note an interesting phenomenon at the foot of the Alerts page. It seems that Tuesday 19th January 2038 already has two activations planned.
Interestingly, K0JQZ has entered no less than four alerts for an activation of W0/FR-165 at 18:00, whilst HB9CKV follows at the earlier time of 10:30 on HB/GR-102.
I’m guessing that this date serves as a “dump” for alerts which have some error within, especially as the time appears in reverse order form other “normal” dates.
73 de Les, GV3VQO
In reply to G3VQO:
“At 03:14:08 UTC on 19 January 2038, 32-bit versions of the Unix time stamp will cease to work, as it will overflow the largest value that can be held in a signed 32-bit number. Before this moment software using 32-bit time stamps will need to either adopt a new convention for time stamps or be migrated to 64-bit systems,[15] and file formats using 32-bit time stamps will need to be changed to support larger time stamps or a different epoch.”
Or the time becomes b11111111111111111111111111111111
Andy
MM0FMF
In reply to MM0FMF:
Forgot this bit…
And I think if you get the month/day aspect of the date wrong you get a date that is here.
Andy
MM0FMF
In reply to MM0FMF:
“At 03:14:08 UTC on 19 January 2038, 32-bit versions of the Unix time
stamp will cease to work, as it will overflow the largest value that
can be held in a signed 32-bit number. Before this moment software
using 32-bit time stamps will need to either adopt a new convention
for time stamps or be migrated to 64-bit systems,[15] and file formats
using 32-bit time stamps will need to be changed to support larger
time stamps or a different epoch.”
French or Latin might make more sense to me Andy!!! 
73
Karen 2E0XYL
In reply to 2E0XYL:
Karen,
Just like the year 2000 bug only it is UNIX (instead of windows/DOS) so it is actually a much more serious problem unless sorted out.
Speak soon, I hope,
73,
Rod
In reply to 2E0XYL:
Times are stored in a 32 bit signed number. The range of values you can store in a 32bit number is from -2147483648 to 2147483647. The time is the number of seconds since some fixed point in time. In Unix systems (like Linux which SOTAwatch runs on), the fixed point in time, the Epoch, is 00:00:00 (midnight) Thursday, 1 January 1970 UTC. Leap seconds are not counted in the time.
The time increases by 1 every second. There are 86400 seconds (60sec * 60min * 24hr) per day.
2147483647, the bigest number you can store = 24855 * 86400 seconds. Or the time can be calculated up to 24855 days from Jan 1 1970.
24855 days = 68 * 365 days. So the calendar works upto 1970 + 68 = 2038.
When you get to 2038 then the time value will wrap around and you wont know if it’s 19 January 2038 or 31 Dec 1969 because you have exceeded the range the time can express.
In 1970, 2038 was a long way off so nobody was bothered that there would be a problem with Unix time. Of course nobody expected Unix (Linux, OSX and all the POSIX operating systems) to have been the stunning success they were so nobody expected the same time code to be in use 43 years later. Now we only have 25 years left to fix the issue. So nobody will do anything until 2037 when the “millenium bug” panic will hit again.
So whenever you see 19 Jan 2038 in a time you should, if you are from a POSIX background, immediately suspect that the time value has got borked and overflowed or got broken in someway. It’s a screaming giveaway that the calculation went wrong.
Andy
MM0FMF
In reply to M0JLA:
Thanks for the translation for the Rod. 
73
Karen