Anyone knows the minimum date vale supported by api.box.com for search by created_range and modified_range
The URL for the same is: https://box-content.readme.io/#searching-for-content
From the API docs under Date Format:
Box supports the subset of dates after the start of the Unix epoch: 1970-01-01T00:00:00+00:00 (00:00:00 UTC on January 1, 1970).
Earlier dates may happen to work as well, but this is what's officially supported.
Related
I have exported data from a health app showing my weight that I tracked over the last few years. The app no longer has this functionality so the only way for me to get this data is to read the JSON file and put it into another app. I understand the weight part, as it is KG, instead of LB. I just need help understanding the "Created_at" so I know what date this is from. Is there an easier way to translate this part of the JSON? Based on the timezone offset, it looks like it is in seconds, but that's all I have figured out so far. Any help would be greatly appreciated.
{
"start_time": 1517323800000,
"created_at": 1517323824000,
"updated_at": 1517323824000,
"start_time_timezone_offset": -22000,
"weight": 73.84483783600001,
"origin_type": "manual",
"id": "d1640b9b-c8bd-6b54-5a3c-da492e8ac75a"
}
Milliseconds to date converter helps you to find the date and time from a given total number of milliseconds. This total number of milliseconds is the elapsed milliseconds since timestamp or unix epoch counting from 1 January 1970.
for example: 1517323800000 is Tue 30 January 2018
16:50:00
https://www.timecalculator.net/milliseconds-to-date
The code is:
var rightNow = new Date();
console.log(rightNow);
In Chrome 66 it returns:
Tue Jun 12 2018 15:36:19 GMT+0530 (IST)
In Chrome 67 it returns:
Tue Jun 12 2018 15:36:43 GMT+0530 (India Standard Time)
Why the difference?
A lot of my code works with the behaviour in chrome 66. Do I need to change all the code?
In general, you should not code for a specific browser, but to the standards. In this case, the standard is ECMAScript (ECMA-262). Section 20.3.4.41 covers Date.prototype.toString(), which refers to the following section describing the internal ToDateString(tv) function, which explains:
Return an implementation-dependent String value that represents tv as a date and time in the current time zone using a convenient, human-readable form.
By "implementation-dependent", it means that the actual string value is not defined by the specification, and can vary from one implementation to another. You are not guaranteed the same result from one browser to the next, or from one version of a browser to the next, or even from one operating system to the next from the same version of the same browser.
By "human-readable form", it means that the value produced is suitable for display to a human being. It makes no guarantees about that value being represented in a manner that can be parsed consistently by computer code.
Thus, if you intend for the string value to be sent to other code, you should not use .toString(). In general, you should prefer an ISO 8601 formatted string for this purpose. Use .toISOString() if you want the result in terms of UTC. Refer to this answer (or use a library) if you want the result in terms of local time including a time zone offset.
As to why things changed between Chrome 66 and Chrome 67 - I don't have the exact details, but I assume Chrome switched from using IANA TZDB abbreviations to using CLDR time zone names, probably through its use of ICU. This is reasonable, and is what many other implementations are doing. There's no requirement it use one set of data or the other though, so don't rely on such things.
I'm getting some very odd looking timestamps from netflix's video API, they look like this ;
527637852762
I assume its a timestamp as in the json it looks like this,
"time": 527780548207
How can I convert this ? it should equate to around some day in September 2017.
So far I've tired dividing by 100, 1000 and no luck.
Thanks
Seconds since 1.1.1970?
It is a common unix time stamp
Referring to the Netflix API documentation they say:
For times since the epoch both seconds and milliseconds are supported because both are in common use and it helps to avoid confusion when copy and pasting from another source.
Milliseconds Timestamp to Date
I figured it out, its a 2001 timestamp. Seconds since 2001. So take that figure / 1000 and that converts correctly :)
epochconverter.com/coredata
I am using the HighStock API of HighChart.
The demo:
http://jsfiddle.net/gh/get/jquery/1.9.1/highslide-software/highcharts.com/tree/master/samples/stock/demo/compare/
Makes a timeline on the x-Axis.
But the data JSON data for the graph has the following keys:
E.g. for AAPL:
?(/* AAPL historical OHLC data from the Google Finance API */
[
/* Dec 2008 */
[1229472000000,12.74],
[1229558400000,12.78],
[1229644800000,12.86],
[1229904000000,12.25],
[1229990400000,12.34],
[1230076800000,12.15],
[1230249600000,12.26],
[1230508800000,12.37],
[1230595200000,12.33],
[1230681600000,12.19],
How do all the 1229.... values relate to Date/Time?? I mean how does
1232582400000
relate to 22. January 2009???
And I have data int he following format in Java:
2015-12-10 15:27
How should I use them in the HighChart API?
The numeric time stamps you see as "1232582400000" is the javascript time stamp. I believe it is UNIX epoch time in milliseconds (multiply epoch time by 1000). You can convert your human-readable time values into javascript time in any number of ways. The basic example if you have year, month, day, hour, and second would be to make your data series use Date.UTC():
[Date.UTC(year, month, day, hour, minute), yValue]
"Unix time (also known as POSIX time or Epoch time) is a system for
describing instants in time, defined as the number of seconds that
have elapsed since 00:00:00 Coordinated Universal Time (UTC),
Thursday, 1 January 1970, not counting leap seconds."
(source)
The number 71867806 represents the present day, with the smallest unit of days.
Sorry guy's, caching owned me, it's actually milliseconds!
How can I
calculate the currente date from it?
(or) convert it into an Unix timestamp?
Solution shouldn't use language depending features.
Thanks!
This depends on:
What unit this number represents (days, seconds, milliseconds, ticks?)
When the starting date was
In general I would discourage you from trying to reinvent the wheel here, since you will have to handle every single exception in regards to dates yourself.
If it's truly an integer number of days, and the number you've given is for today (April 21, 2010, for me as I'm reading this), then the "zero day" (the epoch) was obviously enough 71867806 days ago. I can't quite imagine why somebody would pick that though -- it works out to roughly 196,763 years ago (~194,753 BC, if you prefer). That seems like a strange enough time to pick that I'm going to guess that there's more to this than what you've told us (perhaps more than you know about).
It seems to me the first thing to do is verify that the number does increase by one every 24 hours. If at all possible keep track of the exact time when it does increment.
First, you have only one point, and that's not quite enough. Get the number for "tomorrow" and see if that's 71867806+1. If it is, then you can safely bet that +1 means +1 day. If it's something like tomorrow-today = 24, then odds are +1 means +1 hour, and the logic to display days only shows you the "day" part. If it's something else check to see if it's near (24*60, which would be minutes), (24*60*60, which would be seconds), or (24*60*60*1000, which would be milliseconds).
Once you have an idea of what kind of units you are using, you can estimate how many years ago the "start" date of 0 was. See if that aligns with any of the common calendar systems located at http://en.wikipedia.org/wiki/List_of_calendars. Odds are that the calendar you are using isn't a truly new creation, but a reimplementation of an existing calendar. If it seems very far back, it might be an Julian Date, which has day 0 equivalent to BCE 4713 January 01 12:00:00.0 UT Monday. Julian Dates and Modified Julian dates are often used in astronomy calculations.
The next major goal is to find Jan 1, 1970 00:00:00. If you can find the number that represents that date, then you simply subtract it from this foreign calendar system and convert the remainder from the discovered units to milliseconds. That will give you UNIX time which you can then use with the standard UNIX utilities to convert to a time in any time zone you like.
In the end, you might not be able to be 100% certain that your conversion is exactly the same as the hand implemented system, but if you can test your assumptions about the calendar by plugging in numbers and seeing if they display as you predicted. Use this technique to create a battery of tests which will help you determine how this system handles leap years, etc. Remember, it might not handle them at all!
What time is: 71,867,806 miliseconds from midnight?
There are:
- 86,400,000 ms/day
- 3,600,000 ms/hour
- 60,000 ms/minute
- 1,000 ms/second
Remove and tally these units until you have the time, as follows:
How many days? None because 71,867,806 is less than 86,400,000
How many hours? Maximum times 3,600,000 can be removed is 19 times
71,867,806 - (3,600,000 * 19) = 3,467,806 ms left.
How many minutes? Maximum times 60,000 can be removed is 57 times.
3,467,806 - (60,000 * 57) = 47,806 ms left
How many seconds? Maximum times 1,000 can be removed is 47 times.
47,806 - (1,000 * 47) = 806
So the time is: 19:57:47.806
It is indeed a fairly long time ago if the smallest number is in days. However, assuming you're sure about it I could suggest the following shell command which would be obviously not valid for dates before 1st Jan. 1970:
date -d "#$(echo '(71867806-71853086)*3600*24'|bc)" +%D
or without bc:
date -d "#$(((71867806 - 71853086) * 3600 * 24))" +%D
Sorry again for the messy question, i got the solution now. In js it looks like that:
var dayZero = new Date(new Date().getTime() - 71867806 * 1000);