I would like to the current date minus a previous begin date with the result with the result being the number days there is a difference of the two?
I have attempted the following: date_sub(Begindt, INTERVAL current_date)
Also, will I have to cast things differently?
Below is for BigQuery Standard SQL
DATE_DIFF(CURRENT_DATE(), Begindt, DAY)
See more for DATE_DIFF()
Above assumes the Begindt field is of DATE type
If not, you should cast to DATE type via CAST or PARSE_DATE functions
Are you finding something like below
DATE_DIFF(Begindt, CURRENT_DATE, day)
Related
In H2 I would like to get the actual timestamp minus 2 months and on the first day of month without the time part?
eg.: 2020-03-09 13:46:55 => 2020-01-01 00:00:00
Thanks a lot
Try this:
select FORMATDATETIME(DATEADD(mm,-2,CURRENT_DATE) ,'Y-MM-01');
SELECT DATE_TRUNC('MONTH', TIMESTAMP '2020-03-09 13:46:55' - INTERVAL '2' MONTH)
/
SELECT DATE_TRUNC('MONTH', LOCALTIMESTAMP - INTERVAL '2' MONTH)
should be used in recent releases of H2. It isn't supported by historic versions, however.
FORMATDATETIME is slow, has different known bugs, and it produces a VARCHAR value that needs an additional implicit or explicit cast back to a datetime value.
I have a dataset in bigquery with a TIMESTAMP column "register_date" (sample value "2017-11-19 22:45:05.000 UTC" ).
I need to filter records based on x days or weeks before today criteria.
Example query
select all records which are 2 weeks old.
Currently I have this query (which I feel like a kind of hack) that works and returns the correct results
SELECT * FROM `my-pj.my_dataset.sample_table`
WHERE
(SELECT
CAST(DATE(register_date) AS DATE)) BETWEEN DATE_ADD(CURRENT_DATE(), INTERVAL -150 DAY)
AND CURRENT_DATE()
LIMIT 10
My question is do I have to use all that CASTing stuff on a TIMESTAMP column (which seems like over complicating the otherwise simple query)?
If I remove the CASting part, my query doesn't run and returns error.
Here is my simplified query
SELECT
*
FROM
`my-pj.my_dataset.sample_table`
WHERE
register_date BETWEEN DATE_ADD(CURRENT_DATE(), INTERVAL -150 DAY)
AND CURRENT_DATE()
LIMIT
10
that results into an error
Query Failed
Error: No matching signature for operator BETWEEN for argument types: TIMESTAMP, DATE, DATE. Supported signature: (ANY) BETWEEN (ANY) AND (ANY) at [6:17]
any insight is highly appreciated.
Use timestamp functions:
SELECT t.*
FROM `my-pj.my_dataset.sample_table` t
WHERE register_date BETWEEN TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -150 DAY) AND CURRENT_TIMESTAMP()
LIMIT 10;
BigQuery has three data types for date/time values: date, datetime, and timestamp. These are not mutually interchangeable. The basic idea is:
Dates have no time component and no timezone.
Datetimes have a time component and no timezone.
Timestamp has both a time component and a timezone. In fact, it represents the value in UTC.
INTERVAL values are defined in gcp documentation
Conversion between the different values is not automatic. Your error message suggests that register_date is really stored as a Timestamp.
One caveat (from personal experience): the definition of day is based on UTC. This is not much of an issue if you are in London. It can be a bigger issue if you are in another time zone and you want the definition of "day" to be based on the local time zone. If that is an issue for you, ask another question.
I want to be able to do something like
SELECT cast(my_date_col AS int) FROM my_table;
I would like to get the integer which MonetDB uses internally, i.e. the value you'd find if you looked into the BAT structure and got the appropriate element in code in MonetDB's GDK. Now, AFAICT, this internal value is the number of days since the Epoch, being Jan 1st on "Year 0" (so January 3rdt year 2 would be 366+365+2 = 732).
The best I could actually manage is
SELECT my_date_col AS int - cast('1-1-1' AS date) - 366 FROM my_table;
As MonetDB won't accept "Year zero" dates. This is rather an ugly hack, I'd like to do better. Help me?
If you're trying to get the number of days between "my_date_col" and 1970-01-01, in standard SQL you'd just subtract the one from the other. Your platform, monetdb, seems to support this syntax, but I don't have it installed. I wrote these examples in PostgreSQL.
select current_date - date '1970-01-01' as num_days;
num_days
--
16213
Check that result by adding 16213 days to the current date (2014-05-23).
select cast ((date '1970-01-01' + interval '16213' day) as date) as target_date
target_date
--
2014-05-23
The cast is necessary, because the result of this addition is a timestamp, not a date.
In your case, you want a column name instead of "current_date". So you're looking for something along these lines.
select my_date_col - date '1970-01-01' as num_days
from your-table-name;
One of my column needs to be transformed into a date field. It contains a value that gives the YYMM and it should be translated into the last day of that month:
For example, 1312 should become 12/31/2013.
I have tried various last_day, to_char functions but not able to convert 1312 in a date format. Please help !!
Netezza is based on Postgres, so maybe the Postgres method will work. Here is Postgres code that works (see here):
select to_date('1312'||'01', 'YYMMDD') + interval '1 month' - interval '1 day'
I would first convert the number to a date, then add 1 month and subtract 1 day.
select add_months(to_date(1312, 'yymm'), 1) - 1 as the_date
I have a problem when running this Oracle SQL statement:
SELECT *
FROM tbl_content
WHERE last_updated >= (systimestamp - INTERVAL '1' month(1))
ORDER BY last_updated desc
And this error:
java.sql.SQLException: ORA-01839: date not valid for month specified
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:111)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:330)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:287)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:742)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:212)
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:951)
at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1053)
at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:835)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1123)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3284)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3328)
at com.vtdd.sms.content.xskt.XsktService.getKQXSFollowArea(XsktService.java:4044)
at com.vtdd.sms.content.xskt.XsktService.getMessages(XsktService.java:421)
at com.vht.sms.content.ContentAbstract.getSubmitMessages(ContentAbstract.java:47)
at com.vht.sms.content.ContentFactory.getSubmitMessages(ContentFactory.java:335)
at com.vht.sms.content.ContentFactory.run(ContentFactory.java:62)
at java.lang.Thread.run(Thread.java:662)
Could you tell me what is wrong?
Firstly, why are you using systimestamp? If you want this to the month then surely sysdate is exact enough? Secondly, I like - i.e. it's personal preference - to make it extremely clear what's happening. Oracle has an add_months function, which will do what you want. So your query could easily be:
SELECT *
FROM tbl_content
WHERE last_updated >= add_months(sysdate, -1)
ORDER BY last_updated desc
What is actually wrong is that interval arithmetic doesn't adjust days - see the 6th bullet in the link:
When interval calculations return a datetime value, the result must be an actual datetime value or the database returns an error.
ADD_MONTHS does; as that link says:
If date is the last day of the month or if the resulting month has fewer days than the day component of date, then the result is the last day of the resulting month.
So, ADD_MONTHS(DATE '2011-12-31', -1) gives you 2011-11-30, while DATE '2011-12-31' - INTERVAL '1' MONTH tries to give you 2011-11-31, which as the message says, isn't a valid date.
(It's debatable if this behaviour is actually wrong; it's unexpected, but I believe it's conforming to ANSI. There may be times you want it to work this way, though I can't think of any...)