weird intervals in postgresql - sql

I am working with postgresql and when i want to calcalute the average of some intervals between
two timestamps. The intervals are correct but I get something like "235 days 29:28:02.642857"
I find it strange that it says 235 days and 29 hours instead of 236 days and 5 hours.

As noted by #pozs, you can use justify_hours(interval) to get them converted properly. If you want to convert the days to months, you may use justify_days(interval). If you want to do both at once, do justify_interval(interval)

Related

DateDiff into Hours and have decimals

I have two times periods from the same day and I am using datediff(Hour,FirstTime,SecondTime)*1.0 to get the hours difference, but it is rounding. I am expecting 4.5 but my results keep coming back as 5.0
I tried casting each time, formatting each time before datediff but the results are the same. I know I am missing a simple solution probably because I am too close to the issue.

Need help converting Integer to Time

I looked through online solutions for this, none worked for me so I'm posting here. I have separate date and time columns, both stored as integers. I am able to convert the date column to DATE, but not for the Time column. The column value is: 52700, when using TO_TIME(TO_CHAR(OHCRTM)) I get 14:38:20 but it should be 07:27:00. I've tried various formatting (TO_TIME(TO_CHAR(OHCRTM),'HH24.MI.SS') but I get a 'cannot parse' error. Any idea how I can get the correct time?
14:38:20 is the right answer, unless you can give us the logic that would make it 07:27:00.
52700 seconds are exactly 14 hours, 38 minutes, and 20 seconds.
Another option to read 52700 would be a time without the colons, ie 05:27:00. To parse it like that the needed SQL is:
select to_time(52700::string, 'HHMISS');
I guess 05 becomes 07 after a timezone conversion then?

limitation on Decorator in Querying unPartitioned Tables in BigQuery? (LegacySQL) [dataset.table_name#-16502400000-]

Greetings my fellow stack overflowers
I'm trying to run a query on the past six months from a none-partitioned table , using decorator, translating 191 days to miliseconds - [dataset.table_name#-16502400000-]
Yet the results show me only the past two months
Is there some kind of a limitation on decorators?
Thanks in advance!
In the documentation is mentioned:
time must be within the last 7 days and greater than or equal to the
table's creation time.
Taking that in to the account, decorators are limited to the past 7 days.

Total Hours Format in Moment.js

I'm creating a data table using DataTables.net where a column contains the cumulative running hours of an event. I'm simply adding to the hours each time, so I have for example:
40:34:30
which is 40 hours, 34 minutes, 30 seconds.
My problem is I want to order this column by hours, and I haven't been able to find anything that supports this from Moment.js. Ideally I imagine it would be something like "HHH:mm:ss", or something like that. As it stands, the column recognises the fields as strings, so 0:12:34 is appearing above anything else in descending order despite only being 12 minutes long.
You can sort HH:mm:ss by re-formating it to seconds before sorting.
moment.duration('40:34:30').asSeconds;
gives you 146070. Then simply use seconds in your sorting script.
here is the solution: jsFiddle
And if you really need just the hour part; use Math.floor: jsFiddle

Google Bigquery table decorators

I need to add decorators that will represent from 6 days ago till now.
how should I do it?
lets say the date is realative 604800000 millis from now and it's absolute is 1427061600000
#-604800000
#1427061600000
#now in millis - 1427061600000
#1427061600000 - now in millis
Is there a difference by using relative or absolute times?
Thanks
#-518400000--1
Will give you data for the last 6 days (or last 144 hours).
I think all you need is to read this.
Basically, you have the choice of #time, which is time since Epoch (your #1427061600000). You can also express it as a negative number, which the system will interpret as NOW - time (your #-604800000). These both work, but they don't give the result you want. Instead of returning all that was added in that time range, it will return a snapshot of your table from 6 days ago....
Although you COULD use that snapshot, eliminate all duplicates between that snapshot and your current table, and then take THOSE results as what was added during your 6 days, you're better off with :
Using time ranges directly, which you cover with your 3rd and 4th lines. I don't know if the order makes a difference, but I've always used #time1-time2 with time1<time2 (in your case, #1427061600000 - now in millis).