I am making following request for Snapchat API:
GET https://adsapi.snapchat.com/v1/ads/7e4ebe9a-f903-4849-bd46-c590dbb4345e/stats?
granularity=DAY
&fields=android_installs,attachment_avg_view_time_millis,attachment_impressions,attachment_quartile_1,attachment_quartile_2,attachment_quartile_3,attachment_total_view_time_millis,attachment_view_completion,avg_screen_time_millis,avg_view_time_millis,impressions,ios_installs,quartile_1,quartile_2,quartile_3,screen_time_millis,spend,swipe_up_percent,swipes,total_installs,video_views,view_completion,view_time_millis,conversion_purchases,conversion_purchases_value,conversion_save,conversion_start_checkout,conversion_add_cart,conversion_view_content,conversion_add_billing,conversion_searches,conversion_level_completes,conversion_app_opens,conversion_page_views,attachment_frequency,attachment_uniques,frequency,uniques,story_opens,story_completes,conversion_sign_ups,total_installs_swipe_up,android_installs_swipe_up,ios_installs_swipe_up,conversion_purchases_swipe_up,conversion_purchases_value_swipe_up,conversion_save_swipe_up,conversion_start_checkout_swipe_up,conversion_add_cart_swipe_up,conversion_view_content_swipe_up,conversion_add_billing_swipe_up,conversion_sign_ups_swipe_up,conversion_searches_swipe_up,conversion_level_completes_swipe_up,conversion_app_opens_swipe_up,conversion_page_views_swipe_up,total_installs_view,android_installs_view,ios_installs_view,conversion_purchases_view,conversion_purchases_value_view,conversion_save_view,conversion_start_checkout_view,conversion_add_cart_view,conversion_view_content_view,conversion_add_billing_view,conversion_sign_ups_view,conversion_searches_view,conversion_level_completes_view,conversion_app_opens_view,conversion_page_views_view
&swipe_up_attribution_window=28_DAY
&view_attribution_window=1_DAY
&start_time=2018-10-05T00:00:00.000-08:00
&end_time=2018-10-19T00:00:00.000-08:00
Getting following Error:
{
"request_status": "ERROR",
"request_id": "5bf3f47e00ff060ab0faf7f4330001737e616473617069736300016275696c642d30666635373463642d312d3232302d350001010c",
"debug_message": "The start time should be start of a Local Time Zone day for DAY query.",
"display_message": "We're sorry, but the data provided in the request is incomplete or incorrect",
"error_code": "E1008"
}
Certain date ranges will work and others won't. It also doesn't matter what timezone offset (Europe/London +00:00, Los Angeles, -08:00) I use or how I format the request dates (2018-10-01T00:00:00Z, 2018-10-01T00:00:00.000, 2018-10-01T00:00:00.000-08:00, etc) for the ad stats request date range, the error will come back the same. The error has a code but it's not detailed in Snapchat's documentation. All they say is "it's a bad request".
For example, one ad would let me query 29/10/2018 to date or even 29/10/2018 to 30/10/2018 but as soon as I change it to 28/10/2018, it fails with the same error.
There's no apparent start/end times on ads as I thought it might be related to that. It's also not related to the campaign start/end times in this one case we tested.
API DOC: https://developers.snapchat.com/api/docs/?shell#overview
Solved the issue with above error. I forgot to consider the day light saving while passing the timezone offset.
For e.g. We need to check if there is day light saving for the start_time or end_time and adjust the offset accordingly for that timezone.
Related
I am trying to get a handle on the interaction between DateTime.Now and ISO-8601 timezone designation for an API I am working on. An endpoint incorporates a timestamp as criteria for the interrogation of our data historian. The EndPoint returns the nearest previous 1/2 hour average for the datapoint requested and incorporates the following code:
If criteria.EndTime = "" Then
timeStamp = DateTime.Now
Else
timeStamp = CType(criteria.EndTime, DateTime)
End If
The body of the post accepts the following json:
{
"Interval": "30m",
"StartTime": "",
"EndTime": "2022-04-21T00:45:00Z",
"TagList": "PointName",
"Delim":",",
"PointSource": "P",
"ServerName": "PIServer"
}
Where the EndTime is the parameter picked up by the endpoint. We are currently in British Summer Time i.e. DST is UTC +01:00. With the above criteria the data I get back is timestamped as follows:
[
{
"PointName": "PointName",
"TimeStamp": "21/04/2022 01:30:00",
"Value": "-2.3607"
},
{
"PointName": "PointName",
"TimeStamp": "21/04/2022 01:30:00",
"Value": "-2.6333"
}
]
As you can see the data returned is for 01:30 rather than the 00:30 that is expected. If I leave the 'Z' designation out of the criteria then I get the correct content returned. Can someone explain what is happening here please.
Let's assume the client sent UTC based time (yours is) and the server responds in UTC time (it does not). As described, ...T00:30:00Z (00:30:00 UTC) is the correct answer to your input of ...T00:45:00Z based on what you said the endpoint does.
Now let's say the server responds in BST (which, it seems to) to the same UTC based client request. Then ...T01:30:00 (no time zone designation, assumed to be BST) is the correct answer for your input because 00:30:00 UTC is equivalent to 01:30:00 BST, which is the correct result given the server's rules.
I think you've missed the fact that the server appears to always be returning BST (perhaps that's local to the server) without a time zone designation (i.e. you could argue it should be returning T01:30:00+1:00)
It appears that if you send UTC (or any other time with time zone info), you get a BST response with no time zone designation, and if you send a time with no time zone info, the server assumes you're sending BST, and still returns BST.
So, when you remove the Z from your request, you get what you think is the wrong answer, but isn't because T00:45:00 (aka 00:45:00 assumed BST) the server will respond with T00:30:00 (aka 00:30:00 assumed BST).
I suspect if you sent T00:45:00+1:00 you'd get back T00:00:00+1:00, but if you don't (i.e. no to zime zone info), then it might be a server bug. You could test this by sending T00:45:00+2:00 and seeing if you get back T00:00:00+2:00 or not.
When attempting to send an event via post to your api in version 4, I am sending
"data"=>
{"id"=>"bfc50100-02eb-11e9-b178-db8890d0b369",
"name"=>"Name of Event",
"type"=>nil,
"description"=>nil,
"start_epoch"=>1343815200,
"end_epoch"=>1343869200,
"archived"=>0,
"deleted"=>0,
"is_public"=>0,
"status"=>"ACTIVE",
"has_time"=>1,
"timezone"=>nil,
"legacy_id"=>nil,
"created_at"=>"2018-12-18T17:38:36.000Z",
"updated_at"=>"2018-12-18T17:38:36.000Z",
"industry"=>nil}}
And receiving success from your API, but when going to the url for this event, I am seeing the date formatted as 1/18/70, though in Unix time this should be showing as 8/1/2012.
This occurs with all dates. Am I missing something? Is there another date format you would like? The term epoch led me to believe that you wanted a standard unix timestamp.
you need to send unix time stamp, e.g., 1545326867 - which is in milliseconds
When processes like GBP Subscription/Member Enrollment/Member Endorsement are performed and when these processes are accepted, the system throws an error as:
“Object of the class type aWFOperationAssignment cannot be stored in
the database with the corresponding NSID, ID & Version”
and the transaction is roll-backed with the below error shown in the error report.
“The transaction is roll backed. Err Code= 22007.
ErrMsg=SQLState=22007 . [Microsoft][SQL Server Native Client
10.0]Invalid time format”.
This happens only in few of the environments. Not sure if this is a code or configuration issue.
This issue is caused because of the “Bank Holidays Context” configuration in Wynsure.
In the Bank Holidays (Business Administration -> General Settings -> Bank Holiday), the End Time is supposed to be configured in 24 hr time format. If this is configured as for example: 8 for start and 5 for end time, instead of 8 for start and 17 for end time, then the duration is calculated incorrectly. Note that Wynsure tries to subtract the start time from the end time (in this case, it tries to subtract 8 from 5 and gives an incorrect duration)
This configuration will cause an issue while processing any transactions because at the completion of any transaction a corresponding operation is created with 2 fields viz., “Expected Limit Date” and “Expected Limit Time” and this field uses the difference between the “End Time” and “Start Time” to calculate the expected date and time limit.
As the difference between the End Time & Start Time will return an incorrect value, an invalid date & time will be calculated and the system will throw an error with the invalid date and time format and the transaction is rolled back.
To fix this issue, the “End Time” should be configured in 24 hr time format.
I am trying to get the last modification time of a file in S3 using the ObjectMetadata method getLastModified(), as in the following snippet of code:
S3Object s3obj= some_s3_object;
Date someDate = s3obj.getObjectMetadata().getLastModified();
// What time zone is someDate in?
I'm getting back a value, but I am wondering what time zone it is in, and if I can rely on that being in the same time zone? I can't find a reference to the time zone in the docs or anywhere else - maybe I missed it somewhere?
In the course of using the debugger to examine the actual date value, I discovered the fact that the Date's TimezoneOffset is actually set to PST which is the locale of the server.
Does anyone here knows how to solve the Tibco xpath daylight saving date issue.
The issue was we have one record 03/10/2013 02:00 parsed via Tibco mapping palette with following format (mm/dd/yyyy hh:mm). However, it got invalid date time error with above date. It worked with all other times, e.g. 03/10/2013 01:00, 03/10/2013 03:00, just not working with anytime between 03/10/2013 02:00 ~ 03/10/2013 02:59.
The current xpath we using parse-dateTime(format, string)
So, can xpath detect the daylight saving automatically with the inbound date format (mm/dd/yyyy hh:mm) and parse it?
Thanks so much.
James
Yes. The TIBCO function that parses dateTime does detect Day Light Saving.
I think you have two options to handle these cases in your engine.
Change the code to have a Java Code parse the dateTime. I am aware
that java correctly returns the time with 1 hour added in this case.
You should be able to do a TimeZone.getDefault() to get the server's
default TimeZone.
Change the java default timezone in the TRA - java.property.user.timezone in the designer.tra I suppose.
I have not tried these. :-)
I had the same problem with DST, trying to parse string 2014-03-30 02:00:00 which does not exist in italian timeZone.
Since the input date was perfectly legit (intended to be in GMT+0) I solved by forcing the timezone with this code. It should work with any other timezone as long as it doesn't support DST.
tib:parse-dateTime("yyyy-MM-dd HH:mm:ss Z"), concat($Start/root/dateTimeFrom, ' +0000')
Enable daylight in deployment.yaml (kubernetes)
- name: BW_JAVA_OPTS
value: "-Dbw.engine.enable.memory.saving.mode=true -Xms1024m -Xmx4096m"