I have to calculate the number of days between two dates and I search and I don't find any similar function available in ADF.
what I've noticed so far is that if I want to get the number of days between 2 columns, it means that the columns must be date columns, but I have timestamp columns (date + time)
how can I transform these columns into Date columns? or do you have other idea?
Using the fact that 86,400 is the number of seconds in a day
Now, using the function
ticks,
it returns the ticks property value for a specified timestamp. A tick
is a 100-nanosecond interval.
#string(div(sub(ticks(last_date),ticks(first_date)),864000000000))
Can re-format any type timestamp using function formatDateTime()
#formatDateTime(your_time_stamp,'yyyy-MM-dd HH:mm:ss')
Example:
#string(div(sub(ticks('2022-02-23 15:58:16'),ticks('2022-01-31 15:58:16')),864000000000))
This is the expression that I used for Data Flow.
toDate(toString({max_po create date},'yyyy-MM-dd')) - toDate(toString(max_datetimetoday,'yyyy-MM-dd'))
max_po, create date and max_datetimetoday are TimeStamp(date + time) columns.
The result is in days.
I want to backfill from a particular date to the latest date(say last working day).
Considering I have total 671 partitions
count .Q.pv / 671j
And we need to backfill for last 10 days
{//backfill function; 0n!x}#'660 11 sublist .Q.pv
Is there any other/better way to provide partition dates to backfill function other then using sublist.
You can use -10#date to get last 10 dates in your hdb.
Another "safer" option would be to use sublist as this will work in the occurrence of you having less than 10 dates in your hdb:
-10 sublist date
To list all dates between two dates you could use the following formula;
q)daterange:{[date1;date2] 1+date1+til date2-date1}
q)daterange[2019.05.29;2019.06.03]
2019.05.30 2019.05.31 2019.06.01 2019.06.02 2019.06.03
This will increment from date1 until as many days as there are between date1 and date2.
Hope this helps
I understand why postgresql uses month,day and second fields to representate the sql interval datatype. A month is not always the same length and a day can have 23, 24 or 25 hours if a daylight savings time adjustment is involved. this is from postgresql documentation.
But I then do not understand why this is not consequently handled both for months and days. see the following query which calculates an exact interval where the number of seconds between two points in time is exactly calculatable:
select ('2017-01-01'::timestamp-'2016-01-01'::timestamp); -->366 days.
postgresql chooses to give a result in days. not in months and not in seconds.
But why is the result days and not seconds? it is NOT defined how long days are (they can be 23,24 or 25 hours long). so why does he not give output in seconds?
Then since the length of months is also not defined, why doesn't postgresql give an output of 12 month instead of 366 days?
He does not care that the length of days is not defined, but obviously he cares that the length of month is not defined.
Why this asymmetrie?
For further explanation, see this query:
select ('10 days'::interval-'24 hours'::interval); --> 10 days -24:00:00
you see that postgresql correctly refuses to answer with 9 days. He is pretty aware of the problem that days and hours cannot be interchanged. But then again why does the first query return days?
I can't answer your question, but I think I can point you in the right direction. I think the book SQL-99 Complete, Really is the most accessible source for understanding SQL intervals. It's available online: https://mariadb.com/kb/en/sql-99/08-temporal-values/.
SQL standards describe two kinds of intervals: year-month intervals and day-time intervals. It does this to prevent month parts and day parts from appearing in the same interval, because, as you already know, the number of days in a month is ambiguous. The number of days in the interval '3' month depends on which three months you're talking about.
I think this is the verbose, standard SQL way to write your first query.
select cast(timestamp '2017-01-01' - timestamp '2016-01-01' as interval day to hour) as new_column;
new_column
interval day to hour
--
366 days
I suspect that you'll find that SQL standards have rules for what a SQL dbms is supposed to do when things like interval day to hour are omitted. PostgreSQL might or might not follow those rules.
postgresql chooses to give a result in days. not in months and not in seconds.
Standard SQL prevents month parts and day parts from appearing in the same interval. Also, the range of valid seconds is from 0 to 59.
select interval '59' second;
interval
interval second
--
00:00:59
select interval '60' second;
interval
interval second
--
00:01:00
I'm going through this list of dates and times and I've been googling for a few days now and haven't figured out this time format:
201612102200038814 -> 10.12.2016 19:01
201611182200029224 -> 18.11.2016 11:55
201611162200028449 -> 16.11.2016 19:06
2016080521998919 -> 5.8.2016 19:47
2016091522320593 -> 15.9.2016 18:53
It's obvious that the first 8 digits (20161210) are YYYYMMDD, but latter part doesn't make any sense to me....
Do you have any ideas? Is it even a valid time format?
It seems to be some kind of timestamp, since 2,200,029,224 is very close to 2,200,028,449, and the dates of each are only 2 days apart. So the difference is 775, and the date difference is roughly 1.75 days.
The difference between the first two is 9590, which is larger, which makes sense since the difference between those dates is almost a month.
The oldest date you have in the list also has the smallest timestamp, which is consistent with this theory.
The ratios also match up. 775 / 1.75 days = 442. 9590 / 22 days = 435. If I calculated exact seconds differences I bet these ratios would match up nearly perfectly. So then each hour the timestamp goes up by 18 (roughly), or 3 every 10 minutes. This is a pretty bizarre timestamp, but it does fit, and can be used to calculate dates from the given timestamp.
I have data from a text file I'm reading into a postgres 9.1 table, and the data looks like this:
451,22:30:00,22:30:00,San Jose,1
451,22:35:00,22:35:00,Santa Clara,2
451,22:40:00,22:40:00,Lawrence,3
451,22:44:00,22:44:00,Sunnyvale,4
451,22:49:00,22:49:00,Mountain View,5
451,22:53:00,22:53:00,San Antonio,6
451,22:57:00,22:57:00,California Ave,7
451,23:01:00,23:01:00,Palo Alto,8
451,23:04:00,23:04:00,Menlo Park,9
451,23:07:00,23:07:00,Atherton,10
451,23:11:00,23:11:00,Redwood City,11
451,23:15:00,23:15:00,San Carlos,12
451,23:18:00,23:18:00,Belmont,13
451,23:21:00,23:21:00,Hillsdale,14
451,23:24:00,23:24:00,Hayward Park,15
451,23:27:00,23:27:00,San Mateo,16
451,23:30:00,23:30:00,Burlingame,17
451,23:33:00,23:33:00,Broadway,18
451,23:38:00,23:38:00,Millbrae,19
451,23:42:00,23:42:00,San Bruno,20
451,23:47:00,23:47:00,So. San Francisco,21
451,23:53:00,23:53:00,Bayshore,22
451,23:58:00,23:58:00,22nd Street,23
451,24:06:00,24:06:00,San Francisco,24
It is from a timetable for a commuter rail line, Caltrain. I'm trying to query stations, to get train arrival and departure times. I did this several months ago in MySql, and I got
select * from trains as a, trains as b where a.trip_id=b.trip_id and a.st
op_id='San Antonio' and b.stop_id='San Carlos' and a.arrival_time < b.arrival_ti
me;
So far so good, pretty straightforward. However, when I tried copying the data into a postgres database, I got an error for the various columns that had times after midnight, either 24 or 25:00:00 something. However, if I change them to be 00:00:00 and 01:00:00 something, won't that mess with the query? A time after midnight will appear to be before the starting time? MySql apparently didn't have a problem with those times, and I'm not sure what to do. I'm thinking I should use the last column, or maybe convert the times to something that doesn't take into account PM/AM?
You should try using the interval type for the time columns. Those will keep track of the number of hours, minutes, and seconds instead of trying to record a time of day.
See the PostgreSQL documentation on dates and times.
An interval can have a time component greater than 24 hours, unlike the time datatype that is confined to 00:00 <= x <= 23:59.