Have you cleared your browser cache for sotadata.org.uk?
Also, what version of Chrome?
I cleared all the history for the last week on Chrome, I think it was working up till then.
Version details below.
Version 90.0.4430.72 (Official Build) Built on Ubuntu , running on LinuxMint 18 (64-bit)
That’s very old. Latest is 130.
1 Like
…on an OS that’s 8 years+ old, and hasn’t seen updates in 3 years.
Basically, the way things go these days is that there are so many security issues in software running on the web that web developers have to work very hard to ensure that their software is kept up to date as best they can, which usually breaks compatibility with older browsers. We’re then left with a choice - leave the software vulnerable for the large portion of users who keep their browsers up to date, or support comparatively ancient software.
As we’re volunteers here on the SOTA IT side, you get a bit of the best of both worlds. I don’t have the time to keep things super up-to-date so you get some lag in supporting older browsers almost by accident. But every so often, we do have to update, and that’s going to make your 3.5 year old browser not work on every site any more - and as I’ve said many times before, you probably shouldn’t have such a system connected to the internet anyway.
1 Like
That went out of support in Nov 2022 and probably there’s something in the browser that no longer works with our web frameworks. Same for Andy’s version of Chrome.
I’ve tested now using a Debian12 Linux laptop just updated now. Working with Brave 1.117.114 Chromium 130 and also Firefox 128.3.1esr.
The fact that a number of older disparate systems and browsers have suddenly stopped all around the same time suggests that there is something older browsers no longer work with. Sorry don’t know what.
2 Likes
What’s not working for me from at least 2 different computers is opening any of the resources like activation notes from sotl.as. Anyone else having this issue?
This is a SOTL.as issue
1 Like
I’ve always the same problem !
If I use Sotadata3 my QSO with Christophe F5UBH is registered
and I click “back to AM région” I got that :
On my log in SOTAData.org.uk the QSO is on 
And also on (SOTLAS) is OK
I’m using Firefox V131.0.3 (64bits) and before I cleared the cache.
I hope I was clear this time 
73, Eric
F5JKK
1 Like
I see the same issue. Sotadata3 shows I haven’t activated or chased any summits in the G/NP region but click on Sotadata3 and it shows I have activated G/NP-028 42 times.
2 Likes
Fixed.
3 Likes
Many thanks @VK3ARR Andrew 73
1 Like
I have had no difficulty accessing the database, but there is a remaining issue which may help explain some of the problems discussed above.
I just worked F/DL6GCA/P on FL/VO-190 at 10/23/14:26, 28 MHz. CW. The correct information is displayed in my chaser data. But when I go to the SOTA Summits site for that summit, it incorrectly shows the contact was made on 10/22, not 10/23. The same issue is shown for my other recent chases.
This symptom suggests that either (1) there are two different databases, or (2) the databases are using different clocks.
73, Don AC7P, Texas
I just logged OK4US/P on OK/JM-011 on 10/23 15:07 and my
chaser info on that site is also lagging a day. It shows chased 10/22.
I’ll go back and check other data.
73, Gary K3TCU
There’s one database but you are using a different clock to the database 
This is known about and is in hand and is all to do with some bigly changes that are coming “Real Soon Now™”. Just make sure the data on the database pages is correct and everything else will slot into place.
3 Likes
Neither is true. Basically, there is an API that returns an activation date in a format known as ISO8601. The API has historically returned that format without an accompanying timezone offset. Your browser displays all dates in the local timezone unless otherwise specified. It interprets the no-timezone date as being in local time, and the browser is told to display it as if it’s in local time. However, the date is in UTC, and so the browser displays the UTC time as if it’s local time, and you’re none the wiser.
Now, not including a timezone offset in the API means the date is sometimes not parseable by downstream tools, and they need to add an offset manually, so I’ve been going through and adding a timezone offset to make the date proper ISO8601. But now, I need to find everywhere that date is displayed in SOTAData and tell it to not convert the time to local time and instead display it as UTC. Sometimes I miss a few spots, because not all dates are ISO8601 yet, so it’s still a case-by-case basis.
For most people, this isn’t an issue, because they are east of UTC, so the conversion just makes the date a bit later in the day, but still displays the correct date. But for Americans, they’re west of Greenwich, so negative UTC offsets, which sends it back to the previous day.
This is doubly tragic, of course, as having worked for an American company for almost 20 years, I have rarely found any American that seems to understand any timezones that might exist beyond Eastern, Central, Mountain and Pacific 
(and in the time I took to write this, a fix should have built)
2 Likes
Andrew - Thanks for the explanation. This clearly adds to evidence that we Americans are literally “behind the times.” - 73, Don
4 Likes