I just posted an alert for W1/MB-004 today at 1930Z and it is not showing up, despite doing it twice. I believe it should show up immediately, so perhaps something is not right with the system.
73,
Barry N1EU
In reply to N1EU:
Barry, I suspect that you inadvertantly entered the date in the US format - 05/02/2012. SOTAwatch will accept such a date in the past without comment, but will obviously not display it. I tried a test using the 02/05/2012 format, and everything appeared as expected.
Hope that helps.
73 de Les, G3VQO
In reply to G3VQO:
Thanks very much for the quick detective work Les. Yes, you were quite correct (duh).
73,
Barry N1EU
In reply to N1EU:
You have to forgive the UK-centric view of things Barry. I’m looking at internationalising the database so that things like dates work as people expect. i.e. those with a US/VE home association get to enter the date in, what is to Europeans, assbackwards format. Likewise changing the use of ’ , ’ and ’ . ’ in numbers for UK/Europeans is feasible. I’m playing with making the selection automatic rather than manual as that way I don’t have to write an options page. The downside is people get used to entering date the “wrong” way and get confused when it changes on them. Likewise allowing CSV uploads to get the date correct would help, probably by having a field to flip the date.
We won’t go into better support for non-Roman alaphabets other than to say it’s being played with! Just ideas at present though.
Andy
MM0FMF
In reply to MM0FMF:
What about entering it another way, like the total days of a year.
Like, date of activation: the 243th day of the year.
Hi… kidding
In reply to MM0FMF:
I was born and raised in the US and even I think the mm-dd-yy format is assbackwards. I usually use a dd-mm-yyyy format most of the time although I think a yyyy-mm-dd format makes the most sense because it keeps the least significant digit to the right. Using a drop-down menu to select the date would also work, although it would be a slightly slower process. But maybe slowing things down would also help people enter accurate dates.
Doug, ND9Q
In reply to MM0FMF:
.
Andy, would it end the assbackwards problem and the slash entry problem with one stroke if you required the first three letters of the month, instead? 29APR12, e.g. And if the day turns out to be a single digit, could your machine supply the leading zero? 1JAN12 becomes 01JAN12.
.
Elliott, K6ILM
Always Trouble
In reply to K6ILM:
In reply to MM0FMF:
.
Andy, would it end the assbackwards problem and the slash entry
problem with one stroke if you required the first three letters of the
month, instead? 29APR12, e.g. And if the day turns out to be a
single digit, could your machine supply the leading zero? 1JAN12
becomes 01JAN12.
That’s actually my preferred format, but one problem is that it is English-language-centric in contrast to a numeric format.
Barry N1EU
In reply to N1EU & K6ILM:
Some background… I have to admit to being primarily an embedded software type of guy. After that I tend to write software for Linux based machines and after that I write Windows software. However, my main PC is Windows, yes peverse as that may be and its replacement will be Windows too! It’s only in the last 18months I’ve been maintaining the database for SOTA and I’ve had to learn about databases and the framework the SOTA database software uses. Programming is programming, it’s just a matter of learning what’s already been written and tested by others rather that reinventing the wheel everytime. Although learning the amazing power of T-SQL is quite daunting at first. The point to all this rambling is that the framework used for the database software is rather nice. For a Unix/emebedded person to praise the work of Satan (Oracle, no Google, er no Microsoft) is praise indeed. But the libraries of code are vast and extensively tested.
Yes, there’ll be bugs etc. but in general there is a huge amount of library code to be used. Having been burnt by simply subtracting 1 from the year value to move back one year in time and producing the date 29-Feb-2011 (FAIL!) and breaking things I try wherever possible to use the tested library code. So rather than subtracting 1 from the year directly I now know subtract 365 days from the complete date. The library code knows all about leap years and gets the caluclation correct. i.e. 29-Feb-2012 - 1 year = 1-Mar-2011 Moreover you can trust it to be right and I don’t have to test it. Which is nice.
The entire framework is designed to work for many languages/national standards and alphabets. So when it comes to dates the sheer flexibility of formats supported is staggering. The database sets itself to “en-GB” and dates are thus British. Setting the locale to “en-US” and we get bass ackwards dates. Setting it to “de-DE” (I think) and the thousands separator changes from the UK standard of 1,000,000 to 1.000.000. So it’s not a huge amount of work to note the home association when a user logs in and set the locale correctly. Then today would be 2/5/12 for me (or 02/05/2012 or 02-May-12 or 2-May-2012) and 5/2/12 would be today for you left-pond guys.
Date parsing for the users locale is just a few lines of code. If I had to provide a features for setting preferences then the job is much, much bigger. The impact of the change is massive though. Many people have been using the database for a long time and are used to it being British in format. If it suddenly became “local” for people there would be much grief when trying to enter dates and my email inbox would fill up fast. I need to provide some method for enabling the smart mode.
Changes like this are easy to try and changes which improve the user process are always well received. Brian’s request for multi-entry is sadly a significant change to how chaser entries are structured which is why it’s right down the list. There is one downside to leveraging the internationalisation of the codebase and that is it is more like to parse gibberish and accept it as valid data. e.g. the current date has to be dd/mm/yy for chasing. If you enter a different pattern it gets rejected (I haven’t tested it but there is parsing code to check dates). If I allow smart parsing then there is a bigger chance of junk entering the database. Sometime last year, before both of you got addicted to SOTA I think, I did a big hardening job on the CSV entry code. Before you could get all sorts of bogus frequencies into the database like 18m when 18MHz was meant or 17m. That was a case of making the parser more picky and it reduced the chance of junk values getting in the database by nearly 100%.
I’m happy to play about with some smart input parsing as I continuously evolve the code which is why these discussions are useful. I get to gauge what bugs people and explain why some of what they ask for is reasonable and will be implemented and what is reasonable but won’t be implemented.
But Barry’s awards checker is the current #1 job.
Andy, MM0FMF
Database Manager.
In reply to MM0FMF:
.
Understood…As an aside, English is now the official (mandatory) language for international aviation and maritime, and has become nearly so for DX.
.
Elliott, K6ILM
.
Be a Hero
Get Glass
In reply to ND9Q:
I think a yyyy-mm-dd format makes the most sense
Yes, this format has many advantages, and has the additional merit of being an internationally recognised standard (ISO 8601).
For some evangelism on this subject from the place where I work, take a look at:
Martyn M1MAJ
In reply to MM0FMF:
Date parsing for the users locale is just a few lines of code. If I
had to provide a features for setting preferences then the job is
much, much bigger.
Given that you can already choose your home association (and that choice must be recorded somewhere in the database), would it really be that much harder to allow selection of the preferred locale independently? I’m thinking of choosing from a fixed set, not every possible combination.
In reply to M1MAJ:
Yes
Andy
MM0FMF
In reply to M1MAJ:
Many years ago when I was an active amateur astronomer, I preferred y-m-d format, but the most sensible arrangement was for variable star observations for the AAVSO, which used Julian Date (JD) where the concept of the year was abandoned, days were numbered from an arbitary origin, and time was expressed as a decimal part of a day. It has a lot to recommend it, no more leap years to tangle you up, for starters!
73
Brian G8ADD
In reply to M1MAJ:
Interesting article, Martyn. I have been using the YYYYMMDD notation for labelling all my computer files ever since the 8.3 length restriction was removed and also for any other labels that might one day be sorted. To my mind the ability to sort properly (as text or numeric) is the principal advantage of the notation for personal use, apart from the avoidance of US/GB confusion.
73,
Rod
In reply to MM0FMF:
Yes
In that case, my opinion would be that you shouldn’t do it at all. I’d hate to have a format forced on me just because of where I happen to live.
In reply to M1MAJ:
I guess it is one of those cases where the “added value” is significantly less than the effort-cost involved to add the value.
73
Richard
G3CWI