I need to create a date to be stored in mysql. The date is 5 days from now. I thought maybe CakeTime::dayAsSql('+5 days') but I'm missing a parameter which the documentation doesn't describes and also I dont really know if this will give me what I need. Any ideas?
Have you read the documentation at all? I'm asking because CakeTime::dayAsSql() is clearly not what you want:
Returns a partial SQL string to search for all records between two
times occurring on the same day.
Use CakeTime::format():
echo CakeTime::format('+5 days', '%B %e, %Y %H:%M %p');
Related
Good Morning All.
I have a comment field from an invoice system. The user goes into the invoice and leaves a comment/note on it. The source system tags each note with a date. However, the month is either a single digit or a double digit based on the date the note was entered same with the day. So the issue I am having is that I want to pull all of the invoice notes that start with a certain time period. So the notes always start like either one of these:
6/7/16 7:51 AM
11/11/16 8:11 PM
Is there a way to pull the date from the beginning of the note say using AM or PM as the starting point and working back to the beginning of the string?
What I can tell is that you might use Regular Expressions to extract the date from the string, but SQL server doesn't support the regular expression!
A work around is to use CLR, here an article that explain how to achieve what you want. Regular Expressions in MS SQL Server 2005/2008
To get some help on how to build the regular expression to match the dates, here another article that might help you : Regular Expression Library
The date regular expression could be ((\d{2})|(\d))\/((\d{2})|(\d))\/((\d{2})) ((\d{2})|(\d)):((\d{2})|(\d)) [AP]M
Hope this will help you
How do I get last years same week data?
I used fq=trans_date:[NOW-1YEAR/DAY-7DAY TO NOW-1YEAR/DAY] on date field which will give me last 7 days data for last year. But that approach doesn't take into account calender weeks.
It's probably easier to calculate the boundaries for your week number last year in the frontend and then query Solr with the date interval. That way you can get the behavior you want regarding sundays/mondays as well.
Solr does not provide a nice way to do this.
It would be really cool if you could do fq=trans_date:[NOW-1YEAR/WEEK TO NOW-1YEAR/WEEK] but this is not supported.
Nevertheless, you could create a quick function using php or javascript using each language's native Date operators and get the Week number from today to produce start and end points to feed solr in a query like [1995-12-31T23:59:59.999Z TO 2007-03-06T00:00:00Z].
It's pretty straight forward to use
echo JHTML::calendar('', 'date', 'dob', '%Y-%m-%d'); to get the date as 2014-07-01. Is there a way to get Tue 07-01? I don't need the year. I can't find any reference to getting the actual day of the week.
The bit you need to update is %Y-%m-%d - This is formatting the date.
I think it is using this system : http://ellislab.com/expressionengine/user-guide/templates/date_variable_formatting.html and so %D %m-%d should work, though I haven't had chance to test that.
edit: %a seems to work instead of %D for the day
I am trying to query some data out of Home Bank using the data file it produces.
This is a transaction that appears in the file:
<ope date="734309" amount="-14.24" account="4" dst_account="0" paymode="0" flags="1" payee="239" category="2" wording="" info="" tags="" kxfer="0" />
I am interested in the date="734309". I've not seen this format before so don't know how to parse it.
The application is written in C if that is any help.
734309 / 365 = 2011.80548
So I guess it's something like "days since 1 January in the year 1". If you know the actual date that that number should represent, you can reconstruct the precise offset from there.
It's probably the result of the SQL TO_DAYS() function, which represents the number of days since the first day of 1 A.D. (I don't know whether TO_DAYS() is specific to MySQL or if it's a standard SQL function.)
I've written a stored procedure that takes in a date parameter. My concern is that there will be confusion between American and British date formats. What is the best way to ensure that there is no ambiguity between dates such as 02/12/2008. One possibility would be for users to enter a date in a format such as 20081202 (yyyymmdd). Is there any way to validate that without using sub strings? Alternatively dates could be entered as 02-Dec-2008(dd-mmm-yyyy), but again verification is not trivial and there are potential issues with users who do not use English.
Further to the first three answers . . . One issue is that I'm expecting this stored proc to be called directly without a front end so validation ouside of the proc is not an option. Is it a good idea to take the day, month and year as separate parameters?
You won't have any problems whatsoever if you'd use parameters in your sproc:
create proc dbo.Sproc
#date datetime
as
...
If you declare the parameter as being of type DATETIME or one of the other typed date/time types in SQL Server, which you should, then there is no ambiguity; it represents a particular date and time. The type of validation you're talking about should happen outside the stored procedure, not inside.
OK from your comments and edit, it appears the issue is with the way people call the SP rather than actually within it. To that end, you simply need to train your users to use sortable date format, i.e.
yyyy-MM-dd HH:mm:ss
And then there is no ambiguity. Anybody who is allowed near a database should be aware of localisation issues and should always be using a non-ambiguous format like this one when entering dates.
I've ended up taking a string paramater for the date and require users to enter the month as a word. I check the input is a valid date by converting it to date. To ensure the month is entered as a word, I use the like comparator to compare the input string with "%Jan%" or "%Feb%" or "%Mar%" etc.
If your proc accepts the date as a datetime parameter then there is little you can do to validate that the desired format is ddmmyyyy and not mmddyyyy. It all depends on how the user entered the date and how it was passed to SQL.
For example: On a web page i could add a parameter like this
command.Parameters.AddWithValue("#mydate",mydateVar.ToString("dd/MM/yyyy"));
OR
command.Parameters.AddWithValue("#mydate",mydateVar.ToString("MM/dd/yyyy"));
And SQL will just insert what its given as long as the string can be cast to a date correctly. It wont know the format you want to use so it will try to cast to its system default format.
A solution i use although it may not be applicable in your situation is to have users enter all dates in whatever frontend you have in the dd-MMM-yyyy format. I can then be sure of the format before i insert into the DB. I use that format everywhere to keep it all the same throughout the app.
You said that you are expecting this stored proc to be called directly without a front end and validation ouside of the proc is not an option.
In that case the users will be inserting data directly, I also believe that in this case it is for internal use only (as the stored proc is going to be called directly)
So I think you have 2 options
if you have disciplined users you can agree on one of the safe formats: ISO yyyyddmm, or ISO8601 yyyy-mm-dd Thh:mm:ss:mmm if you need a time part as well
otherwise take 3 parameters: year, month, year and perform some validation inside the stored procedure
I say take a datetime and train them to use the ODBC canonical form of a date as in this example:
EXECUTE uspMyProc {d '2009-02-11'}
If you take a date that you have to parse, whether it be a string or the year, month and day as separate integer arguments, then you have to deal with days out of range for the month and year. Some functions that take those automatically advance or move backwards the day on you. Thus the trick of sending 0 for the day and getting the last day of the previous month. Others return an error. But handling that stuff yourself is probably not worth reinventing the wheel.
If you absolutely have to because novices will be running it directly (why would novices be running stored procedures directly?), I'd take three separate arguments and pass the concatenated date as a string in the format YYYY-MM-DD through ISDATE to verify the parameters and exit if it isn't valid.