I use invoiced API
https://invoiced.com/docs/guides/subscription-billing
and I got records like
"renewed_last": 1493732122,
"renews_next": 1496410522,
"start_date": 1493732122,
What those magic numbers mean? I thought this is milliseconds from 1970, but it's not true. They can render data properly on their site, but I can't get date for me app. How to get date from those magic numbers?
According to the api docs all dates are in unixtimestamp
https://en.wikipedia.org/wiki/Unix_time
It is timestamp in seconds from Jan 1 1970, Java calculates time in millisecond
So the solution is
new Date(unixTimestamp * 1000L);
Related
I want to get two fields: Begin date and End date of last month. For example, 14-04-2020 should give me the Begin date as 01-03-2020 and End_date as 31-03-2020. I have read the Nifi Expression language docs but all it can do with a date format is add or subtract in milliseconds. This is not helpful for my use case as the number of days in a month is not fixed and conversion to milliseconds won't help.
Is there a way to achieve my use case somehow using Nifi Expression language?
#AdarshKumar
NiFI Expression Language for this Use Case would be very clunky and unreliable for different timezones, months with <> 30 days, and leap years.
Please reference this post below which goes into detail for how to get "last month":
How to insert previous month of data into database Nifi?
In the Case of NiFi you kind of have to play with the dates to get the outcome
if you have the dates you easily convert a date and then just hard set a day to get the 1st day of the month with a hard coded day
${now():toNumber():format('yyyy-MM-01')}
to get the last day of the month you can either use the script or play with the calc using epoch time.
so to get the last day of the previous month you can just use the date and convert the day into epoch time and subtract it from the epoch date to get last day of previous month
example
${now():toNumber():format('yyyy-MM-dd'):toDate('yyyy-MM-dd', 'GMT'):toNumber():minus(${now():toNumber():format('dd'):toNumber():multiply(86400):multiply(1000)}):format('yyyy-MM-dd')}
in this example above we convert the date to epoch format it to convert again, conversion happens to remove default timestamp and then we use the same formula to get just the day as a number to multiply it with 86400 seconds in a day and multiply that by 1000 for the epoch number to subtract from the date which is then formatted back into a date.
Raw Date: Thursday, August 26, 2021 11:20:31 AM
formatted: Thursday, August 26, 2021 12:00:00 AM
epoch of formatted date: 1629936000000
Subtract Epoch: 2246400000 (86400 seconds * 26 days * 1000)
result: 2021-07-31
alteratively you could first add a month and the work back to get the current day of the given month
this example is just to give you an idea of ways you can use built in date functions with epoch time to calculate the correct date, removing the issues with months that end on specific numbers.
I try UpdateAttribute to minus month
test${now():toNumber():format('yyyyMM'):minus(1)}01
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.
in my current project I need to work with data from a certain loger. Unfortunately, I encountered a problem of coding the date of this loger. I believed that it is a timestamp date format but it is not. Can you tell me in what format is this datum
Real date:
04-Jan-2018 16:43:16
Date format:
568399396
That date-time format is called epoch, where the date is stored as an integer. It is the number of seconds/milliseconds after 1st January 1970, 00:00:00. This is how all the computers/devices store the date/time internally.
You can use n number of libraries to convert an epoch to date/time etc.
You can read more about epoch here:
https://en.wikipedia.org/wiki/Unix_time
P.s.: Are you sure that you're getting this number for 4th Jan 2018? The epoch of 04-Jan-2018 16:43:16 will be 1515064396000(in ms)
I am getting an exif date value like
EXIFPhotoDate: 1506173228000 and
UploadDate: 1506485214000
but I know it is
EXIFPhotoDate 23/9/2017, 23:27 and
UploadDate 9/27/2017, 01:59
The former is when queried via REST and the latter is when queried via the table.
How can I get standard date/time from a value like this?
Looks like you have a number of milliseconds since January 01 1970 in UTC. If you remove the 000 from the end, you will have a Unix timestamp, that is, the number of seconds since January 01 1970 in UTC:
unixTimestamp = 1506173228000 / 1000
Once your question doesn't state any programming language, it's hard to give you further help.
I don't understand the way the API returns values. Here's a sample of a page_impressions call, with 'week' as the period.
"values"=>
[{"end_time"=>"2012-01-08T08:00:00+0000", "value"=>1116},
{"end_time"=>"2012-01-09T08:00:00+0000", "value"=>1171},
{"end_time"=>"2012-01-10T08:00:00+0000", "value"=>1175}]
It seems that they're showing how many hits I had in the last 7 days up to the date in "end_time", is that correct? If it is, then I don't understand what use this would have, there is a huge overlap in the data.
How can I get the number of impressions of the last weeks instead? And how can I get more than 3 values to display? I really can't understand the logic behind this or how it could be useful.
What's happening here is that you're being given the total number of page_impressions for the 7-day period ending on each of the dates shown (i.e., how many times was the page seen over the past 7 days assuming the week ended on the end_time? and then on end_time+1? end_time+2)
Facebook is returning three (3) separate readings, presumably so you can spot/review very local trends (e.g., "are my weekly impressions creeping up?) or perhaps because you missed a measurement and want to have values for every day.
To answer your question specifically:
The 7-day period 2012-01-01 through 2012-01-08 12:00am* had 1,116 impressions.
The 7-day period 2012-01-02 through 2012-01-09 12:00am* had 1,171 impressions.
The 7-day period 2012-01-03 through 2012-01-10 12:00am* had 1,175 impressions.
As is quoted below, the end_time itself is always midnight in PDT. Thus, an end_time of 2012-01-08 really means the measurement stopped the night before, i.e., at 1 minute past 11:59pm on 2012-01-07.
From https://developers.facebook.com/docs/reference/fql/insights/:
The end of the period during which the metrics were collected,
expressed as a UNIX time (which should always be midnight, Pacific
Daylight Time) or using the function end_time_date() which takes a
date string in 'YYYY-MM-DD' format. Note: If the UNIX time provided is
not midnight, Pacific Daylight Time, your query may return an empty
resultset. Example: To obtain data for the 24-hour period starting on
September 15th at 00:00 (i.e. 12:00 midnight) and ending on September
16th at 00:00 (i.e. 12:00 midnight), specify 1284620400 as the
end_time and 86400 as the period. Note: end_time should not be
specified when querying lifetime metrics.