[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-gis] RE: Question about CAP
Hi I don't really understand what the issue is. In my view, the "04:00" offset in "2008-03-13T10:37:44-04:00" means that the intended time is 14:37:44 UTC. Standard or daylight saving should be playing no role in this calculation. I have to say that I don't know why we are allowing the use of nonzero offsets (that is, timezones other than UTC) in CAP. I don't see the benefits of doing so, but I believe that it may cause confusion. It should be the message creator's responsibility to convert the local time (taking account of daylight saving) to UTC when creating a message. Alessandro > -----Original Message----- > From: Rex Brooks [mailto:rexb@starbourne.com] > Sent: Friday, March 14, 2008 17:15 > To: Paulsen,Norm [Ontario]; Rex Brooks; > emergency-gis@lists.oasis-open.org > Subject: [emergency-gis] RE: Question about CAP > > My pleasure, Norm, > > These are important issues, so I am passing it along to the > appropriate working group, so disregard any bounces from your replies > to me. > > Cheers, > Rex > > At 3:43 PM -0400 3/14/08, Paulsen,Norm [Ontario] wrote: > >Thanks, they do frustrate.... > > > >No more questions, just a few comments. > > > >The specifications use an example that is during daylight time and is > >for the Pacific Time Zone (Art's own time zone). This offset > is -07:00 > >which would indicate that it does reflect the local time (daylight > >adjusted) as PDT is 7 hours off in the summer and PST is 8 > hours off in > >the winter from UTC. This I read as contrary to your answer > below where > >I could just take the value -4 and lookup the time zone. > > > >Unless I know the location and time zone particulars of the CAP > >originating location though its useless to me as I would have to > >maintain lookup tables for all originating sources and keep > them current > >over time which is just a lot of unnecessary overhead that I wouldn't > >want to deal with. With your way (I assume you mean -08 to > mean Pacific > >time zone regardless of time of year) I can just look it up. > In truth I > >prefer your way. > > > >The US is working with UTC in the <expires> and <effective> > tags by just > >not using the offset in those fields. I tend to agree that > is the only > >way to be safe and let the end recipient adjust for local time. > > > >I appreciate your time and answers. Maybe these questions > can be brought > >up within the CAP working group. > > > >Thanks for listening. > > > >Norm > > > >-----Original Message----- > >From: Rex Brooks [mailto:rexb@starbourne.com] > >Sent: March 14, 2008 3:12 PM > >To: Paulsen,Norm [Ontario]; emergency-gis@lists.oasis-open.org > >Subject: RE: Question about CAP > > > >Hi Norm, > > > >I'm sorry if my answer frustrates, but the specification at stage 1.1 > >doesn't say anything directly on these specific issues. I have to use > >what the specification actually says and apply it as best I can. I'm > >sorry I can't give you an authoritative answer. > > > >My best advice at this point is to take the <sent> dateTime value for > >the CAP MessageID and consider it as defining the Time Zone of the > >issuing agency/office. > > > >In regard to case you cite for an <effective> dateTime before a time > >change and an <expires> afterward, these values are defined > only for the > ><area> associated with the <info> element, so you should be able to > >look up the Time Zone based on the <area>. This is not > dependent on the > >location of the CAP issuing office. > > > >I'm doing my best to answer your questions. I apologize, if that's > >insufficient. > > > >Cheers, > >Rex > > > > > > > >>THANKS > >> > >>FOLLOW UP QUESTIONS WHICH ARE MORE TO MY ISSUE > >> > >>1) REGARDLESS OF TIME OF YEAR ... IS <sent> THE CURRENT LOCAL TIME? > >>...OR IS IT LOCAL STANDARD TIME? > >> > >>2) The <effective> and <expires> TAGS ARE FORMATTED THE > SAME AS <sent> > >>SO IF THE <effective> TIME IS BEFORE THE DAYLIGHT TIME > CHANGE AND THE > >><expires> IS AFTER TIME CHANGE IS THE RECIPIENT EXPECTED TO > KNOW THIS > >>AND SEE THIS REFLECTED IN THE TAG VALUE? > >> > >>3) WHAT'S THE POINT OF KNOWING THE LOCAL TIME OF THE CAP > ISSUING OFFICE > > > >>IF THE LOCATION OF THE CAP ISSUING OFFICE IS NOT KNOWN. I > DON'T SEE A > >>TAG THAT GIVES THAT INFO SO WHAT'S THE POINT OF KNOWING THE > LOCAL TIME > >>OF THE CAP ISSUING OFFICE? > >> > >>NORM > >> > >> > >>-----Original Message----- > >>From: Rex Brooks [mailto:rexb@starbourne.com] > >>Sent: March 14, 2008 12:18 PM > >>To: Paulsen,Norm [Ontario]; Rex Brooks > >>Cc: Elysa Jones > >>Subject: RE: Question about CAP > >> > >>Hi Norm, Elysa, > >> > >>I was afraid this might be the issue. NOAA-NWS is slightly > >>non-conformant, so you would have to ask them about the details of > >>their implementation. The dateTime for <sent> SHOULD be for the > >>location of the sender at the time the message was issued and > >>identified by the MessageID. That would, most likely, be for the > >>CAP-issuing office location as you infer. > >> > >> > >> > >> > >>However, when the message is issued by NOAA, I believe, > though I could > > >be wrong, that the <sent> dateTime is for the NOAA-NWS HQ > through which > > > >>alert messages are issued. That would account for the same offset in > > >California and New York. > >> > >>You are correct. The <alert> <sent> dateTime is for the message, not > >>for the <area> associated with the <info> which contains the Onset > >>Date/Time > >>(onset) and Effective Date/Time (effective) directly related to the > >>incident/event. > >> > >>I hope that helps. > >> > >>Cheers, > >>Rex > >> > >> > >>At 11:20 AM -0400 3/14/08, Paulsen,Norm [Ontario] wrote: > >>>Rex > >>> > >>>Thanks for the response and the offer to help.... > >>> > >>>It is the <sent> tag in the <alert> block.. > >>> > >>>Couple of U.S. examples below... > >>> > >>><alert> > >>> <identifier> > >>> NOAA-NWS-ALERTS California 2008-03-13T10:37:44-04:00 > >>> </identifier> > >>> <sender>w-nws.webmaster@noaa.gov</sender> > >>> <sent>2008-03-13T10:37:44-04:00</sent> > >>> <status>Actual</status> > >>> <msgType>Alert</msgType> > >>> <scope>Public</scope> > >>> <note> > >>> Current Watches, Warnings and Advisories for California > >>Issued by the > >>>National Weather Service > >>> </note> > >>> <references> > >>> http://www.weather.gov/alerts/ca.html > >>> </references> > >>> <info> .... </info> > >>> <info> .... </info> > >>> <info> .... </info> > >>> <info> .... </info> > >>></alert> > >>> > >>>And the same for New York State: > >>> > >>><alert> > >>> <identifier> > >>> NOAA-NWS-ALERTS New York 2008-03-13T10:42:25-04:00 > >>> </identifier> > >>> <sender>w-nws.webmaster@noaa.gov</sender> > >>> <sent>2008-03-13T10:42:25-04:00</sent> > >>> <status>Actual</status> > >>> <msgType>Alert</msgType> > >>> <scope>Public</scope> > >>> <note> > >>> Current Watches, Warnings and Advisories for New York Issued by > >>the > >>>National Weather Service > >>> </note> > >>> <references> > >>> http://www.weather.gov/alerts/ny.html > >>> </references> > >>> <info> .... </info> > >>> <info> .... </info> > >>> <info> .... </info> > >>> <info> .... </info> > >>></alert> > >>> > >>>Both have -04:00 as the time zone modifier. The > <identifier> tag notes > >> >California for one alert and New York for the other alert. > >>> > >>>Since they are both -04:00, I assume the <sent> tag is referring to > >>>the > >> > >>>time it was in the location of the office where the CAP alert was > >>>generated regardless of where the hazard was for. Looks like an > >>>Eastern > >> > >>>time zone based on -04. > >>> > >>>If true, to know if -04:00 is EDT (Eastern Daylight)or AST > (Atlantic > >>>Standard) I would need to know the location of the CAP > issuing office. > >>>The CAP standard document uses a Daylight example so it appears its > >>>not > >> > >>>just a local standard time offset, but assuming I even > have a need to > >>>know the time at the location of the issuing office how > would I know > >>>which one it is? > >>> > >>>Is there a place to tag the location and timezone of the issuing > >>>office > >> > >>>without having to resort to a local lookup table? A lookup > table would > > > >>>require maintenance which could more easily be done with a tag for > >>>this > >> > >>>info. > >>> > >>>In the end, daylight or not, UTC can be properly calculated but if > >>>someone in California were to disseminate it locally, they > would have > >>>to work from <sent> to UTC to Pacific time or use what is > later found > >>>in the <description> tag??? > >>> > >>>If this is how its meant to be, what's the point? If I need to know > >>>the > >> > >>>local time at the issuing office then I would need to know the time > >>>zone of the issuing office so as to properly process this > information. > >>> > >>>However, if I don't need to know (and I haven't a reason > figured out > >>>yet why I would), why not just put UTC time in the <sent> tag. > >>> > >>>Thanks > >>>Norm > >>> > >>>-----Original Message----- > >>>From: Rex Brooks [mailto:rexb@starbourne.com] > >>>Sent: March 14, 2008 10:54 AM > >>>To: Elysa Jones; Rex Brooks > >>>Cc: Paulsen,Norm [Ontario] > >>>Subject: Re: Question about CAP > >>> > >>>Hi Norm, > >>> > >>>I would be happy to answer your question. However, I'm not > sure what > >>>is > >> > >>>referred to by "offset value" and to which element is > applied. I did a > > > >>>quick search of the document and neither 'offset' nor > 'offset value' > >>>occurs in the document, so I am assuming that you are > referring to a > >>>specific implementation issue, so if you could clarify > that for me, I > >>>will do my best to answer. > >>> > >>>Cheers, > > >>Rex > >>> > >>>At 8:39 AM -0500 3/14/08, Elysa Jones wrote: > >>>>Rex, > >>>> > >>>>Meet Norm Paulsen of Environment Canada. We were on a call today > > >>>with Norm's organization and OASIS staff. They are > interested in > >>>>joining us to participate with the CAP usage issues, as > well as other > > > >>>>EDXL standards. > >>>> > >>>>He has an immediate question about the CAP Element Tag > wrt the offset > > > >>>>value and why it is determined as it is. He is working an issue > >>>>right > >> > >>>>now and I thought you would be best able to give him an answer. > >>>>Please > >>> > >>>>get in touch with Norm if you can. > >>>> > >>>>Thanks, > >>>>Elysa > >>> > >>> > >>>-- > >>>Rex Brooks > >>>President, CEO > >>>Starbourne Communications Design > >>>GeoAddress: 1361-A Addison > >>>Berkeley, CA 94702 > >>>Tel: 510-898-0670 > >> > >> > >>-- > >>Rex Brooks > >>President, CEO > >>Starbourne Communications Design > >>GeoAddress: 1361-A Addison > >>Berkeley, CA 94702 > >>Tel: 510-898-0670 > > > > > >-- > >Rex Brooks > >President, CEO > >Starbourne Communications Design > >GeoAddress: 1361-A Addison > >Berkeley, CA 94702 > >Tel: 510-898-0670 > > > -- > Rex Brooks > President, CEO > Starbourne Communications Design > GeoAddress: 1361-A Addison > Berkeley, CA 94702 > Tel: 510-898-0670 > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all > your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr oups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]