Cumulus Support

Instead of having something like "Conditions at local time 15:40 on 16 March 2021" could it instead be "Conditions at 15:40 EST on 16 March 2021"? The timezone can be gotten from the locale on the CumulusMX machine. Or, alternatively, have a web tag with the timezone in it so we can roll our own?

The only issue is that MX only has access to the full time zone name, and the standard/DST names.

Eg. Full = "(UTC-05:00) Eastern Time (US & Canada)"
Standard = "Eastern Standard Time"
Daylight = "Eastern Daylight Time"

or for the UK...
"(UTC) Dublin, Edinburgh, Lisbon, London"
"GMT Standard Time"
"GMT Daylight Time"

There are no abbreviated names, and I think the ones above are not really what you are looking for?

I agree, they're not ideal - but better IMHO than "local time". Perhaps just a webtag then, or included in the weather info JSON?

While there is a worldwide list of abbreviated time zone names, those abbreviations are far from unique. I live in British Columbia, Canada, so my time zone is "Pacific Standard Time" (PST). However, somebody living on the Pitcairn Islands in the Southern Pacific would have the "Pitcairn Standard Time" (also abbreviated PST, both UTC-8). Paraguay and Pyongyang (North Korea) both live on PYT. AMST could mean Amazon Summer Time or Armenia Summer Time. Very confusing ...

Maybe the easiest solution would be a new entry "Local Time Zone" in the Cumulus.ini file under Station Settings/General Settings/Location.

KarlS wrote: ↑Tue 16 Mar 2021 10:58 pm Maybe the easiest solution would be a new entry "Local Time Zone" in the Cumulus.ini file under Station Settings/General Settings/Location.

Probably, you can display what you want then.

but how would it cope with DST ?

Two fields then?

mcrossley wrote: ↑Wed 17 Mar 2021 11:52 am Two fields then?

Or change it when the clocks change? Another reason (in addition to the gap in records in March and double-recording in October) to not use DST.

freddie wrote: ↑Wed 17 Mar 2021 2:22 pm

mcrossley wrote: ↑Wed 17 Mar 2021 11:52 am Two fields then?

Or change it when the clocks change? Another reason (in addition to the gap in records in March and double-recording in October) to not use DST.

Do you mean the user changes it? They are bound to forget! My thought was two fields (standard and DST) and the web tag chooses between them depending on DST status.

freddie wrote: ↑Wed 17 Mar 2021 2:22 pm Another reason (in addition to the gap in records in March and double-recording in October) to not use DST.

Move to Arizona, about the only sensible place I know of!

mcrossley wrote: ↑Wed 17 Mar 2021 2:26 pm

freddie wrote: ↑Wed 17 Mar 2021 2:22 pm Another reason (in addition to the gap in records in March and double-recording in October) to not use DST.

Move to Arizona, about the only sensible place I know of!

or Hawaii

As has been said earlier - js is a bit hit and miss with timezones.

The Americas in particular are a problem because a line of longitude passes through many countries.

Again, as said before, Short, abbreviated TZ, may be returned as GMT / UTC offset, whereas long name may be missing, GMT offset, or just (too) long.

eg. Using js intlDateObj

timeZoneName: 'long' New York City: Wed, 17 Mar, Eastern Daylight Time (America/New_York )
timeZoneName: 'short' New York City: Wed, 17 Mar, GMT-4 (America/New_York )

but if you're lucky ..

timeZoneName: 'short' Berlin: Wed, 17 Mar, CET (Europe/Berlin )

You can experiment here