Alarm UI

I just had a proper play with Alarm for the first time and noticed a couple of oddities.

When setting up a new alarm (or editing an existing one), the fields are in the order “Month, Year, Day, Hour, Minute”. Wouldn’t “Year, Month, Day, Hour, Minute” be more sensible (with the “biggest” value on the left and the “smallest” on the right)? The fields are also not labelled, which doesn’t help with comprehension.

When setting a custom format, the option “%tz” for “timezone” has an example of “BST” listed in the User Guide. I can go into “Set clock” and choose the “Locality”, which results in some interesting values for %tz:

• “UK ‘GMT’” results in “BST” (correct)
• “Western Europe” also results in “BST” (presumably incorrect; I think it should be “WET”)
• “New Zealand” results in “Custom” (I’d expect “NZDT”)
• “Pacific” also results in “Custom” (I’d expect “PST”)

I haven’t tried any others, but at a guess I’d say that there would be a lot of “Customs” in there!

Has anyone else run into this?

Month-year-day does sound pretty silly, with or without labels. I think the two most sensible replacement options would be year-month-day (a nice and sensible international standard), or the same as whatever *time outputs (assuming that varies by territory – if not, then year-month-day would likely be the only option).

“Western Europe” also results in “BST” (presumably incorrect; I think it should be “WET”)

Probably a side effect of how crap the Territory implementation actually is. In short, a standard UK machine with UK territory knows only GMT, BST, and “Custom”.

I had to fiddle my RISC OS sources to add understanding of CET and CEST.

It’s been one of my standard whinges for, oh, about the last twenty years…

Changing to Year-Month-Day should be fairly easy; it seems that Alarm doesn’t use the Toolbox but presumably old-style templates are also easy to edit.

As for timezones, does anyone know what would happen if we extended the UK territory to define all worldwide timezones? It would presumably make NZDT etc show up in Alarm, but is it liable to break anything else? Has CET/CEST broken anything for you, Rick?

Has CET/CEST broken anything for you, Rick?

Yes, no, maybe. I think one needs to fiddle with messages to set up the transition of daylight savings. Not sure I’ve done it correctly as it doesn’t. But, then, I’m so used to this being broken that it doesn’t surprise me any more. ;-)

Otherwise, I’ve not noticed any ill effects.

A bigger problem is that there is no such thing as a sensible list of timezone acronyms.

PST? That’s California time, right? Yes, but not entirely…
Pacific Standard Time, UTC−8
Pakistan Standard Time, UTC+5
Philippine Standard Time, UTC+8
Pitcairn Standard Time, thankfully also UTC-8 so is same as Pacific incarnation.

CST – is that American central time (UTC-6), or Australian (UTC+9:30)? The latter is also known as ACST which is just as well for CST could also be China Standard Time (UTC+8) or Cuba Standard Time (UTC-5).

AST – Atlantic (UTC-4) or Arabian (UTC+2) standard time.

Even Blighty’s precious BST doesn’t come out unscathed, for the B could mean Bangladesh (+6) or Bougainville (+11).

Seriously, I could go on for screenfuls. This is why timezone adjustments (Windows, Linux, etc) use a list of cities and not a timezone. If you live in Belarus, your timezone is unambiguous…

Another thing to change in RISC OS’s Territory. Location awareness, and by that I mean a much friendlier system than loading an appropriate module, if one even exists.

Ugh. I assumed that the abbreviations were standardised. It seems that I assumed incorrectly!

Even little ol’ NZ has four different timezones (NZST, NZDT, CHAST, CHADT) depending on location and time of year…

Speaking of Alarm, I noticed that setting the clock in Alarm (on an offline Pi) didn’t actually update the time displayed by Alarm (set to display Analogue, no seconds.) I’ve not had a chance to test it on the most recent SD image, so this may be an issue that’s since been resolved.

I noticed that setting the clock in Alarm (on an offline Pi) didn’t actually update the time displayed by Alarm (set to display Analogue, no seconds.)

Wait for the next minute to go by then it jumps to the right time

Even Blighty’s precious BST doesn’t come out unscathed, for the B could mean Bangladesh (6) or Bougainville (11).

I think that although we tend to refer to that summertime shuffle time as BST it’s actual status is GMT + daylight saving i.e. GMT+1
(or if you want to keep the French happy just refer to UTC+1 – which if they were honest is the same as they should use since the meridian that defines UTC0 runs down only fractionally West of Paris)

which if they were honest is the same as they should use since the meridian that defines UTC0 runs down only fractionally West of Paris

True. I live to the east of Greenwich. However, unlike the current British leadership (on both sides), the French don’t see European integration as a horrific thing…

Wait for the next minute to go by then it jumps to the right time

Since there are a few different things that could cause the time to change (setting the clock in Configure, NetTime, manual OS_ResyncTime, changing territory, etc.) it might make sense to have Alarm always use a 1 second poll interval. Redundant redraws can easily be avoided by checking the displayed time value against the new time value.

However, unlike the current British leadership (on both sides), the French don’t see European integration as a horrific thing…

I’ve just thought of a brilliant compromise:
We send all those tories to France then you guys send them back and we settle on the halfway house – about 10 miles (or 16.5km for the metric users) from Dover and Calais should be near perfect. :)

And then shut the ends of the tunnel? Seems a bit of a waste – maybe a redundant aircraft carrier would be better? We could even scuttle it, if we’re careful to put it in deep enough water not to cause a hazard to shipping.

And then shut the ends of the tunnel? Seems a bit of a waste – maybe a redundant aircraft carrier would be better

My first thought was a roll-on, roll-off (roll-over) ferry but I’m sure something smaller do and would be less chance of a shipping hazard.

You seem to have been drawing the line a little more tightly around the leadership than I might have been… 8~)