I am trying to call Snapchat Marketing API for Ads stats with the end point through Postman
https://adsapi.snapchat.com/v1/ads/<Some Ad ID>/stats?start_time=2019-08-10T00:00:00-04:00&end_time=2019-09-10T00:00:00-04:00&granularity=DAY
Which is throwing as error as
"Unsupported Stats Query: Timeseries queries with DAY granularity
must have a start time that is the start of day (00:00:00) for the
account's timezone. This account's timezone is: Asia/Dubai"
I have tried all the possible combination of start time and end time in (ISO 8601) format.
does anyone know what might be the issue?
Asia/Dubai is +4 , but you used -4, so the start_time should be:
start_time=2019-08-10T00:00:00%2B04:00
You should encode + sign, otherwise it wouldn't work, + ~> %2B
The same should be on end_time, only one or two days after start_time
Related
I'm developing a Clio integration with access to the calendar, but there's been an issue with dates. While the documentation says they expect an ISO-8601 timestamp date, it seems like there's something adding offset to the timezone value in dates being sent to the system.
For example, if I send a date 2018-05-17T23:59:59.999999-04:00 on both start_at and end_at properties when creating a calendar entry for an all day event, the value returned when fetching this entry through the API is 2018-05-17T17:00:00-07:00, which is clearly wrong. Am I missing something here?
The expected result should be something like either 2018-05-17T23:59:59-04:00 or 2018-05-18T03:59:59Z if milliseconds are ignored.
All dates are based on UTC timezone. Could it be that your site/server/script is set to a local timezone and so the dates are off for part of the day?
Try setting your scripting environment to UTC time before making any date/time-based queries.
We have just changed timezone, and it gives me a problem with database
(I am now in the timezone GMT+2).
I have to check when something starts and I use this query :
SELECT *,extract(epoch from start at time zone 'cet') as start_, extract(epoch from stop at time zone 'cet') as stop_ from czas;
and it's wrong, because my start_/stop_ is 1 hour older : i.e that should be 16 instead of 17 and 'cet' should be replaced by 'cest'.
I found QTimeZone class, which should display current short zone name (cet/cest), but when I use it like this :
QDateTime now = QDateTime::currentDateTime();
QTimeZone zone_;
qDebug()<<"ZONE: "<<zone_.displayName(now,QTimeZone::ShortName);
I get an empty string.
Does anyone have an idea why?
I can't answer why QT isn't doing what you expect.
Perhapse I can help with solving the issue you started with which is the issue of using the correct timezone? For this PostgreSQL offers a number of timezone names which are set to the country and not the number of hours offset. For example 'Europe/London' specifies 'GMT' for winter timestamps and 'BST' for summer timestamps.
The list of these has been removed in the 9.x manual but in the 8.1 manual the list can be found here:
http://www.postgresql.org/docs/8.1/static/datetime-keywords.html
For your system use the following to get a complete list of timezone names:
select * from pg_timezone_names;
I don't know which of these is most suited to your application but for example your code could be changed to:
SELECT *,extract(epoch from start time zone 'Europe/Paris') as start_, extract(epoch from stop at time zone 'Europe/Paris') as stop_ from czas;
How can I start charging a user the user immediately for a PayPal billing agreement?
Here's what I've got so far.
Create a Billing Plan (POST .../payments/billing-plans/)
Make it active (PATCH .../payments/billing-plans/)
Create a Billing Aggreement (POST .../payments/billing-agreements/)
Send user to approval_url, user approves, redirected to return url
Execute agreement (POST .../payments/billing-agreements//agreement-execute)
This all seems to work, but I want to charge the user right now and every month in the future. If I set start_date to now in step 3 I get an error, it must be in the future. If I set it in the future the user is not charged.
Do I need to 'Set outstanding agreement amounts' then 'Bill outstanding agreement amounts' for the initial payment?
Also, what about monthly payments, do they require some action or do they just happen as specified in the Billing Plan?
Update
I'm testing this around 2014-09-16T20:06:30+0000
If I send start_date as the current UTC time it get an error at step 2 telling me it must be in the future.
If I send the current date +30 secs or +2 hours I get through to step 5 which returns a 400 response: UNKNOWN_ERROR "An unknown error has occurred"
If I send the current date +4 hours it all works. The current UTC time is 8pm so adding 4 hours means the start_date is tomorrow.
Does this mean I can't charge the user today? Does the start_date have to be in next day or even the next business day?
I've talked to a PayPal rep and found that start_date must be tomorrow or later. They are going to add this to the docs.
If you want to start monthly billing immediately you might be able to do it by setting the start date to be in one months time and charging a setup fee to cover the first month. I haven't tested this as it's not what I want.
First payment for agreements will be billed right on specified start_date. The subsequent amounts are also taken automatically by PP. You need to work with the BillOutstandingAmount calls only if PP failed to pick the payment on the renewal date.
The problem I faced when developing with their RestAPI was specifying a wrong timezone. Maybe this is the same for you. Make sure the proper timezone is specified in your start_date (with all dates given to PP in fact)
Dates should be in this format: yyyy-MM-ddTHH:mm:ssZ
ex. start_date = 2014-09-16T09:20:00-0400
IF you want to make sure Paypal accepts the date as being valid, just add a few seconds to it.
Let's say you are in Java, you can do something like:
private String getPaypalDate()
{
DateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
// Add 30 seconds to make sure Paypal accept the agreement date
Date rightNow = new Date(new Date().getTime() + 30000);
return df.format(rightNow);
}
I used this date format working.
$time = time();
$startDate = date('Y-m-d\\TH:i:s\\Z', $time);
I can't replicate, actually. I stumbled on this thread when getting the error due to setting it to moment.now(). But setting it to even 5 seconds in the future works a-ok. I'm using JavaScript, "start_date": moment().add({seconds:5}).format() and that checks out fine. Moment.js will set TZ to UTC when formatting as such, so it's gotta be a timezone thing on your end?
It looks like the payments just process based on the date being before or after 07:00 UTC of the current date.
For example. The current date time is 2017-05-04T04:50:00.00Z I set my start date to be the current UTC date time plus 30 seconds. Because the agreement date is set to a value greater then the current date time the API doesn't throw an error, but it DOESN'T set your time to be what you specified. Instead it sets it to 2017-05-04T07:00:00Z.
Now, if you have the same date time of 2017-05-04T04:50:00.00Z and instead of adding 30 seconds you add 24hrs you'd think that your time would then be set to be 2017-05-05T04:50:00.00Z. But no, the time will be set to 2017-05-05T07:00:00Z.
So it seems like these just process everyday at 07:00 UTC and you can't specify anything but the date.
I'm developing an app where a user can request that an email be sent to them at a specific time every day in their timezone. For example User A lives in London and schedules an email at 2pm every day London time and User B lives in New York and schedules an email at 2pm New York time.
I'm wondering what way I should configure my database postgres such that a scheduler can fire every minute and query for all emails to be sent at that minute regardless of what timezone their in.
The one thing I want to avoid is having to run multiple queries, once per timezone.
Due to the (rather idiotic, quite frankly) rules for daylight saving times (DST) across the world, a local time can mean all kind of things in absolute (UTC time).
Save a time (not timetz!) and the time zone name (not the abbreviation) for when to send the emails. Tricky details under this related question:
Time zone names with identical properties yield different result when applied to timestamp
CREATE TABLE event (
event_id serial PRIMARY KEY
, alarm_time time -- local alarm time
, tz text -- time zone name
, ...
);
Use the following expression to "cook" the exact daily point in time, taking local DST settings into account:
SELECT current_date + alarm_time AT TIME ZONE tz;
Example:
SELECT current_date + '2:30'::time AT TIME ZONE 'Europe/London' AS alarm_ts
Returns:
alarm_ts
2014-05-19 02:30:00+02
Use timestamp with time zone (timestamptz) across your whole application. Be sure to understand how it works. This comprehensive post may be of help (also explains the AT TIME ZONE construct:
Ignoring timezones altogether in Rails and PostgreSQL
Just to be clear, once you have "cooked" the daily UTC time, you can translate it to and work with any local time just as well. But it might be less confusing to do all the rest in UTC.
What time of day are the periods? For example, if I have 2013-06-02 for "start-date", does that start at the beginning of the day at 00:00? If I have 2014-01-03 for "end-date", does that mean it ends at the end of the day at 23:59?
If this is true, setting "start-date" and "end-date to the same value will mean it will only return data that has happened during that day?
To put in less words, are both the start and end dates inclusive or exclusive?
That's correct. the dates are inclusive. If you set both start-date and end-date to the same value you will get all data for that specific day.
Also worth noting that they respect the time zone you configured in your View Settings.