How to determine local time zone for a given API alert

[JJKraw]

Please describe what you're trying to do.

When displaying an alert on my web site, I'd like to display the times in the correct time zone for the area affected. There is probably an easy way to do this that I'm just missing. Here's what I've found so far.

1. The times contained within the alert (e.g., sent, effective, expires) contain the local timezone offset (e.g., 2021-04-02T06:00:00-04:00 indicates UTC-4). However, a given offset doesn't tell the whole story. Currently this could mean Atlantic Standard Time (e.g. for Puerto Rico) or Eastern Daylight Time. I could figure it out based on time/date and location, but then if the rules change again that code would be wrong.

2. The headline attribute of an alert seems consistent in including the time zone (e.g. "Rip Current Statement issued March 31 at 3:02AM AST until April 2 at 6:00AM AST by NWS San Juan PR"). However, that's a rather kludgy way to get the info and fails if, for some reason, the headline excludes the time zone (but OK for a work-around for now).

Unless I'm missing something, I guess I'm asking for an enhancement to add a "timezone" field to the alert data containing the time zone code.

[scadergit]

The API is a pass-through for CAP XML, and that information isn't provided except for the headline. The API would have to use the same kludge to provide it as a separate property. If I recall, the upstream serice that creates the CAP XML has the same challenge, given the headline is created at the local office and parsed in its entirety from the product. Sorry I don't have a better answer, but that would have to change at the source.

[netbymatt]

I think you're trying to oversimplify the process. It's really two steps, and it relies a bit on your programming language to deal with time zone conversions. I've been successful in PHP and Javascript. First, UTC never changes so the server giving you times as -04:00 is just saying this time is 4 hours behind UTC. That -4 may or may not correlate to the time zone the warning was issued in. If you parse that with your favorite date parsing library it'll account for the -04:00 time zone and almost universally it's stored as a UTC value internal to the programming language.
Here's where it gets tricky. Before you send that time to be displayed to your client you need to know their time zone. On the server this is usually impractical so you send a timestamp like the -04:00 one in question to the client. The client then uses the language features to convert to it's own time zone, which is automatically adjusted for daylight savings where/when appropriate. This varies by platform, but the quick test I just ran in Chrome automatically digested the time as provided by the API and spit it back out in my own local time zone. The conversion to America/Chicago makes sense for the client to automatically do.

new Date('2021-04-02T06:00:00-04:00');
Fri Apr 02 2021 05:00:00 GMT-0500 (Central Daylight Time)

Again, it varies by programming language and where the user is located.
I think the problem that you may be running in to is what time zone is the user located in. This is available when you use the /points/{x,y} endpoint.

[scadergit]

That's effectively what we do for our presentation layers, but they need to be client-side applications. More difficult if fully server-side.

[JJKraw]

Thanks, netbymatt. However, what I'm trying to do is get the times for where the alert is, regardless of where the client is. So if I'm sitting on the east coast and I pull up an alert for California, I still want the info with the text to be the local California (PST or PDT) times. This is what alerts.weather.gov attempts to do also (and gets it right, mostly). It also makes little sense for the headlines to be in one time zone while the other dates are in the client's local time zone.

I've noticed that even the NWS gets this wrong in some cases. For instance, there is currently a marine alert for Hawaii waters where the API headline gives the time in "HADT" if I pull from the API (which is wrong - no DST in Hawaii) but if I pull directly from alerts.weather.gov, it has the same alert correctly with HST and the user display at alerts.weather.gov also converts the XML timestamps to HST. So some entity on the server side knows how to do this correctly. And somewhere between the pull from the CAP XML and the generation of the API alert, the headline timezone gets changed.

Puerto Rico is just the opposite: the API headline contains AST while CAP XML headline has ADT and the displayed dates are also ADT. (Maybe the alerts.weather.gov display uses the headline timezone to decide?).

It seems that there IS something to fix here so that the NWS's own alert displays (alerts.weather.gov and if there is any successor based on the API) are correct and the headlines passed on to the API are also correct.

[scadergit]

Current alerts.weather.gov parses text products from the office to create its own CAP XML using lots of kludge (we draw straws to see who has to perform updates on that application). With the transition to CAP 1.2, that effort is now upstream with the API as pass-through. From what I hear, eventually, the offices will create their own CAP XML.

If there are inconsistencies with CAP products on alerts and API you can report those to the helpdesk and they will route them to the service that currently creates the CAP XML.

[JJKraw]

OK, thanks. I will not volunteer to help with the alerts.weather.gov code, although that sounds like fun (I've had to deal with enough "fun" code in my lifetime :) ). I'll see what I can patch together on my own.

Thanks for the info!!

[jah1007]

Could you provide the alert id (urn.....) for the Hawaii CAP? The generating application for CAP XML recently was modified under NWS SCN 21-01.

https://www.weather.gov/media/notification/pdf2/scn21-01cap_handler_v2aac.pdf

Also, please submit the information to NWS Tech Control. I think the contact information is in the readme but for reference here, it is [email protected].

[JJKraw]

There is currently a small craft advisory via the API that has the ID:

urn:oid:2.49.0.1.840.0.1d97f63b56cd75d74b6b3fced23bc9fe796d2001.001.1

The headline is:

Small Craft Advisory issued March 31 at 4:30PM HADT until April 1 at 7:00PM HADT by NWS Honolulu HI

Note that when the nwsHeadline field is non-null and contains a timezone, it is usually correct and is in this case:

SMALL CRAFT ADVISORY NOW IN EFFECT UNTIL 6 PM HST THURSDAY