I'm trying to retrieve historical data for coinbase products. According to their documentation, it should be sufficient to perform a request like this one:
curl "https://api.pro.coinbase.com/products/BCH-EUR/candles?granularity=60&start=2018-10-05T14:00:00.000z&stop=2018-10-05T14:10:00.000z"
I've set following parameters:
granularity to 60 (seconds)
start to 2018-10-05T14:00:00.000z (iso 8601)
end to 2018-10-05T14:10:00.000z (iso 8601)
I'm asking data for 10 minutes, with a granularity of 60 seconds, so I was expecting ten candles data.
Instead I obtain a set of 300 candles, that's the maximum, and the timestamps are also wrong. For example the first value is:
[
[
1624119060,
484.31,
484.31,
484.31,
484.31,
0.11766122
],
...
]
The timestamp is the first value, and according to an epoch converter, it's equal to Saturday, 19 June 2021 16:11:00, that's the day in which I performed the request, not the timestamp that I was expenting for that candle data according to start date that I've set.
I don't know what I'm doing wrong. What should I do in order to retrieve data correctly?
It should be end, not stop. You quote the doc correctly, but the param itself is incorrect. Already voted to close this one as typo-based. :)
What's funny about their API is that if one of the params is omitted, another is just ignored. That's why you end up having incorrect timestamps in your response.
Related
Is anyone able to help me convert the lastLogon and lastLogonTimestamp from Active Directory? I am pulling the data with Power Query and for my own user name I and the data is returned like this:
[users.lastLogonTimestamp]=131804496023891686
[users.lastLogon]=131808141012537325
I found this page on Microsoft Docs which states very clearly:
This value is stored as a large integer that represents the number of
100-nanosecond intervals since January 1, 1601 (UTC). A value of zero
means that the last logon time is unknown.
However I am struggling to get a logical result. I have tried converting nanosecond to days, and then adding the days integer to the starting date '1/1/1601' result. Since I have been actively logging in, I should be getting a date result around today's date, '09/10/2018'.
131804496023891686 / 86,400,000,000,000
= 1525.5150002765241435185185185185
_
1525 + '1/1/1601' = Wednesday, March 6, 1605
-- REFERENCES:
1) https://www.calculateme.com/time/nanoseconds/to-days/
2) https://www.timeanddate.com/date/dateadded.html?m1=01&d1=01&y1=1601&type=add&ay=&am=&aw=&ad=1525&rec=
3) https://learn.microsoft.com/en-us/windows/desktop/adschema/a-lastlogon
Okay so this is a DOH! moment... The answer was staring me in the face. I missed the fact that this was represented in 100 nanoseconds not 1 nanosecond.
(131804496023891686*100) / 86,400,000,000,000
152551.50002765241435185185185185
_
152551 + '1/1/1601' = Thursday, September 13, 2018
NOTE: So this result is actually 3 days in the future... not perfect, but what I am really looking for is just "Active accounts in the last 30 days", so I will consider this acceptably accurate.
This article was also helpful-- http://www.selfadsi.org/ads-attributes/user-lastLogonTimestamp.htm.
So, for PowerShell, I put all together as following
(Get-Date '1601-01-01').AddDays([long]::parse($objItem.lastlogon)*100/86400/1000/1000/1000)
I am using the AMAZON.DATE slot and I would like it to default to past dates.
For example, if a user says Monday I would like it to automatically select last Monday rather than next Monday.
In the documentation it confirms that it defaults to 'on or after the current date':
"Utterances that map to a specific date (such as "today", "now", or
"november twenty-fifth") convert to a complete date: 2015-11-25. Note
that this defaults to dates on or after the current date (see below
for more examples)."
For my application there is no way a future date would make sense so it wouldn't be too difficult to manually program this in but I just wondered if there was any other way of doing it?
No, you cannot change the behavior of built in slots, so if Alexa resolves user's answer as a date - before passing it to your further processing just subtract 7 from resolved value. It will give you the date in the past.
We are using JavaMail API to send calendar entries. But the recipients of Outlook have time zone issues, as meetings show wrong timings. In general our approach is as follows:
First of all we have,
SimpleDateFormat iCalendarDateFormat = new SimpleDateFormat("yyyyMMdd'T'HHmmss");
we then use iCalendarDateFormat.setTimeZone(TimeZone.getTimeZone(receiverTimeZone));
Finally, we use Calendar.getInstance() for start and end to manipulate Calendar fields,
and hence we have Date startDate = startTime.getTime();
Date endDate = endTime.getTime();
When we are about to send request as per icalendar specification we have ,
"DTSTAMP:" + iCalendarDateFormat.format(startDate) + "\n" +
"DTSTART:" + iCalendarDateFormat.format(startDate)+ "\n" "DTEND:" + iCalendarDateFormat.format(endDate)+ "\n"
Is this the correct approach?. Please comment.
Thanks
tl;dr
iCalendar format tracks the date-time separately from its intended time zone. You must juggle both parts appropriately.
Always use java.time classes. Never use legacy classes like Calendar & SimpleDateFormat.
Details
Caveat: I have not used iCalendar data before. So I may be incorrect in my understanding.
Looking at pages 31-33 of the RFC 5545 spec, it seems the authors of that spec assume you always want the date-time to be recorded separately from the time zone.
A moment, a point on the timeline, needs the context of a time zone or offset-from-UTC. For example, "noon on the 23rd of January next year, 2021" is not a moment. We do not know if you mean noon in Tokyo Japan, noon in Toulouse France, or noon in Toledo Ohio US — all very different moments, several hours apart.
To provide the context of an offset, a date and time must be accompanied by a number of hours-minutes-seconds such as 08:00. For an offset of zero hours-minutes-seconds, use +00:00.
2021-01-23T12:00:00+00:00
As an abbreviation of an offset of zero, +00:00, the letter Z can be used, pronounced “Zulu”. For example:
2021-01-23T12:00:00Z
But, strangely, the iCalendar spec wants to track the date and the time-of-day separate from the time zone. So this:
2021-01-23T12:00:00
…and a time zone field elsewhere:
America/New_York
And the iCalendar spec opts for the harder-to-read “basic” variation allowed by ISO 8601, which minimizes the use of delimiters. So this:
20210123T120000
For such a string, we must parse as a LocalDateTime. This class represents a date with a time-of-day but lacking any time zone or offset-from-UTC.
DateTimeFormatter f = dateTimeFormatter.ofPattern( "uuuuMMdd'T'HHmmss" ) ;
String input = "20210123T120000" ; // “Basic” variation of ISO 8601 format.
LocalDateTime ldt = LocalDateTime.parse( input , f ) ;
To determine a moment, we must apply a time zone. I assume iCalendar uses proper time zone names (Continent/Region format) and not the 2-4 letter pseudo-zones such as PST, CST, IST, and so on.
String zoneName = receiverTimeZone ; // Variable name taken from your code example, though you neglected to show its origins.
ZoneId z = ZoneId.of( zoneName ) ;
Apply the zone to get a ZonedDateTime, a moment, a point on the timeline.
ZonedDateTime zdt = ldt.atZone( z ) ;
Going the other direction, let's start with the current moment.
ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
ZonedDateTime now = ZonedDateTime.now( z ) ;
And generate string values for iCalendar.
DateTimeFormatter f = dateTimeFormatter.ofPattern( "uuuuMMdd'T'HHmmss" ) ;
String iCal_DateTime = now.format( f ) ;
String iCal_ZoneName = now.getZone().toString() ;
Never use the terrible legacy date-time classes bundled with the earliest versions of Java: Calendar, GregorianCalendar, java.util.Date, SimpleDateFormat, and so on. These were supplanted years ago by the modern java.time classes defined in JSR 310.
Hard to tell without seeing the actual content of your iCalendar file, along with the expected start and end datetime with timezone information but you seem to be generating the DTSTART in floating time (datetime with local time). Although your code sample seems to imply that you have access to the recipient's timezone (receiverTimezone), this is a very fragile approach.
Instead, you should use either the datetime with UTC time or the datetime with local time and timezone (where the timezone does not have to be the receiver timezone).
If the event is not recurring, the most simple approach is to use datetime with UTC time.
See https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5 for the definition of each format.
I had same problem, for which I struggle lot. So below are my findings:
Outlook works smoothly with UTC Timezone. If we set date & time with UTC Timezone then outlook automatically converts this UTC Time into user corresponding Timezone. We will have to use 'Instant' object for DTSTART:, DTEND: and for DTSTAMP(Optional but recommended) also.
Quick Test just use "DTSTART:"+Instant.now() in ical String.
And in Java 8 for getting UTC Time java time API provides Instant.now() through which you can get your system time in UTC format. Java 8 also provides method like
a. Instant.ofEpochMilli() - This returns Instant which can directly use in ical Sting.
b. new Date().toInstant() Which returns UTC Instant object.
There are few scenarios where input date and time sources are different:
If you are fetching Date and Time from database then in this case database is not storing Timezone its only saving Date & Time. So first convert the Date & Time in that Timezone in which it was saved in database, in my case I was storing Date & Time after converting in 'EST' Timezone and Date value was of EST but time zone was not there in DB. So while fetching Date & Time value from DB I have appended Timezone in the Date value and then further converted to EPOC time using below method
public static long getEpocTimeWithTimezone(Date date) {
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
DateTimeFormatter dateTimePattern = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
LocalDateTime dateTime = LocalDateTime.parse(simpleDateFormat.format(date), dateTimePattern);
long epochInMilliSeconds = dateTime.atZone(ZoneId.of("America/New_York")).toEpochSecond() * 1000;
return epochInMilliSeconds;
}
Then Just Use as below code for ical String:
Instant startDt = Instant.ofEpochMilli(getEpocTimeWithTimezone(//pass your date here
)).truncatedTo(ChronoUnit.MINUTES);
Now set this Instant object(startDt) directly to "DTSTART:":
"DTSTART:"+startDt+"....then in same fashion "DTEND:" also.
In second scenario you have Date with Timezone (make sure after conversion you did not loses your actual Timezone, Like in 1st scenario after saving Date in DB we actually lost Timezone but it was showing Timezone IST that was dummy so be careful about this)
So in this case just assume myDateObject is Date object. So just get the Instant (which
will be in UTC) object from myDateObject by using toInstant() of Date class.
Instant startDt = myDateObject.toInstant().truncatedTo(ChronoUnit.MINUTES);
I am using .truncatedTo(ChronoUnit.MINUTES); because if we will not use this then
we might get some extra min or second in Meeting invite Time section.
So the final String for outlook mail should be some like:
.
.
.
"BEGIN:VEVENT\n"+
"DTSTART:"+startDt+"\n"+
"DTEND:"+endDt+"\n"+
.
.
.
VVI Note: Since Z is representation of UTC time zone, So just adding Z in the last of Time will not be UTC zoned Time, You will have to convert the Date & Time then only accurate time will come on Outlook. For verifying your Time is in UTC format or not just save the .ics attached file (which you got in Email) in local and check Date & Time are coming as DTSTART:2020-05-15T13:57:00Z or not If not then you are not converting the Date correctly in UTC.
What am I doing wrong in this query?
SELECT * FROM TreatmentPlanDetails
WHERE
accountId = 'ag5zfmRvbW9kZW50d2ViMnIRCxIIQWNjb3VudHMYtcjdAQw' AND
status = 'done' AND
category = 'chirurgia orale' AND
setDoneCalendarEventStartTimestamp >= [timestamp for 6 june 2012] AND
setDoneCalendarEventStartTimestamp <= [timestamp for 11 june 2012] AND
deleteStatus = 'notDeleted'
ORDER BY setDoneCalendarEventStartTimestamp ASC
I am not getting any record and I am sure there are records meeting the where clause conditions. To get the correct records I have to widen the timestamp interval by 1 millisecond. Is it normal? Furthermore, if I modify this query by removing the category filter, I am getting the correct results. This is definitely weird.
I also asked on google groups, but I got no answer. Anyway, for details:
https://groups.google.com/forum/?fromgroups#!searchin/google-appengine/query/google-appengine/ixPIvmhCS3g/d4OP91yTkrEJ
Let's talk specifically about creating timestamps to go into the query. What code are you using to create the timestamp record? Apparently that's important, because fuzzing with it a little bit affects the query. It may be relevant that in the datastore, timestamps are recorded as integers representing posix timestamps with microseconds, i.e. the number of microseconds since 1/1/1970 UTC (not counting leap seconds). It's also relevant that dates (i.e. without a time) are represented as midnight, i.e. the earliest time on that day. But please show us the exact code. (It may also be important to show the actual content of the record that you're attempting to retrieve.)
An aside that is not specific to your question: Entity property names count as part of your storage quota. If this is going to be a huge dataset, you might pay more $$ than you'd like for property names like setDoneCalendarEventStartTimestamp.
Because you write :
if I modify this query by removing the category filter, I am getting
the correct results
this probably means that the category was not indexed at the time you write the matching records to the data store. You have to re-write your records to the data store if you want them added to the newly created index.
The Google App Engine memcache documentation states that the time parameter of memcache.set() is an "Optional expiration time, either relative number of seconds from current time (up to 1 month), or an absolute Unix epoch time."
So I tried to set a value for 30 days, which according to Google is 2 592 000 seconds.
However, I highly suspect that this value is too high, because the value was set (memcache.set() returned the value True), but a memcache.get() just after always returned None. Reducing this value to 1 728 000 seconds just worked fine/as expected.
I guess that once passed the highest value, the time parameter gets interpreted as an absolute Unix epoch time. That would mean that 2 592 000 seconds got interpreted as "Sat, 31 Jan 1970 00:00:00 GMT", which is obviously a date in the past...
So what is the highest value you can enter that will get interpreted as a number of seconds in the future?
Edit: On the local dev server, 2 592 000 second worked OK, but not on the production servers. I suppose both servers have a different interpretation of the values.
Your linked Google documentation is oddly imprecise; the actual memcached documentation is more specific, saying the number may not exceed 2,592,000 (30 days of seconds). So in theory, that should have worked, barring implementation issues. (That statement is echoed in the PHP documentation for its memcache stuff.) So according to the memcached docs, your first value should have worked.
I don't suppose 2,591,999 works? The Google doc does say "up to one month", which if you assume 30 days in a month (not a valid assumption) would be up to 2,592,000 (e.g., but not including). That's at odds with the memcached docs, but perhaps there's an implementation difference or something.