Loading ...
Sorry, an error occurred while loading the content.

Re: [yws-searchmarketing] Re: BasicReportRequest: startDate and endDate changed when report is returned

Expand Messages
  • Yahoo! Search Marketing Monkey
    ... There s no modification going on on the server side. It s interpretation. Remember that the server won t know what timezone you are in, so you need to
    Message 1 of 9 , Nov 30, 2006
    • 0 Attachment
      > Okay, the sample .NET code doesn't implement the BasicReportRequest
      > object and the other line explaining .NET implementation of the
      > timezone specifically states "if your accounts reside in the same
      > time zone as the servers that are running the code, you do not need
      > to modify your code.". Why is the BasicReportService modifying my
      > timezone when the report is returned? The WSDL translates the date
      > properties in the BasicReportRequest to the Date type...not
      > dateTime.

      There's no modification going on on the server side. It's
      interpretation. Remember that the server won't know what timezone you
      are in, so you need to specify dateTime with a timezone offset properly.
      I'm not sure what you meant by the last sentence.

      > Again, what time should I use for the start and end dates? 12am to
      > 11:59pm? Or does it matter? Since I am requesting the report in PST
      > will the report return the correct information for that date (even
      > though the report shows an earlier date with the PST timezone) or is
      > it actually the previous day's statistics?

      Assume that the date returned is indeed the date reported on. If you
      pass in a dateTime object with UTC offsets, you'll get the correct
      expected response. I am not 100% sure about using 12am or 11:59pm, but
      a small bit of experimentation should do the trick. Reports really
      aren't able to be pulled for specific times, only full days, so using
      dateTime is a bit of a misnomer, but still the required usage for now.

      Hope this helps,
      -Y!SM Monkey
    • jim_nicholsonva
      ... I m not sure if anyone is still replying to this thread, but here goes So from what I gather, all I have to do in order to ensure the correct reporting
      Message 2 of 9 , Jul 24, 2009
      • 0 Attachment
        --- In yws-searchmarketing@yahoogroups.com, "Yahoo! Search Marketing Monkey" <plummerm@...> wrote:
        >
        > > Okay, the sample .NET code doesn't implement the BasicReportRequest
        > > object and the other line explaining .NET implementation of the
        > > timezone specifically states "if your accounts reside in the same
        > > time zone as the servers that are running the code, you do not need
        > > to modify your code.". Why is the BasicReportService modifying my
        > > timezone when the report is returned? The WSDL translates the date
        > > properties in the BasicReportRequest to the Date type...not
        > > dateTime.
        >
        > There's no modification going on on the server side. It's
        > interpretation. Remember that the server won't know what timezone you
        > are in, so you need to specify dateTime with a timezone offset properly.
        > I'm not sure what you meant by the last sentence.
        >
        > > Again, what time should I use for the start and end dates? 12am to
        > > 11:59pm? Or does it matter? Since I am requesting the report in PST
        > > will the report return the correct information for that date (even
        > > though the report shows an earlier date with the PST timezone) or is
        > > it actually the previous day's statistics?
        >
        > Assume that the date returned is indeed the date reported on. If you
        > pass in a dateTime object with UTC offsets, you'll get the correct
        > expected response. I am not 100% sure about using 12am or 11:59pm, but
        > a small bit of experimentation should do the trick. Reports really
        > aren't able to be pulled for specific times, only full days, so using
        > dateTime is a bit of a misnomer, but still the required usage for now.
        >
        > Hope this helps,
        > -Y!SM Monkey
        >

        I'm not sure if anyone is still replying to this thread, but here goes

        So from what I gather, all I have to do in order to ensure the correct reporting dates is to convert the local dateTime to UTC prior to submitting the request. Is that right?
      Your message has been successfully submitted and would be delivered to recipients shortly.