I am working on creating a search mechanism where the user can specify which fields to search on, the operators to use and the values to search for. More like an advanced search. However, I also need to search for dates and date ranges but the problem is that dates are declared as NSStrings and not NSDates. So basically they are strings that represent dates (and not literally dates as I am referring to them as). An example of a string that represents a date in the database is: 2014-11-25T00:00:00+1000.
So, without changing the values and their respective fields to NSDates in a migration, is there a way to keep what we already have but instead specify a sort of conversion criteria for my predicate query so that Core Data can convert the NSString field values to NSDates and then do the comparison to determine weather a record fits into the specified criteria or not?
I'm fairly sure that CoreData can't convert NSStrings into NSDates for you, what you'll have to do is create a parsing algorithm that converts it for you. The format looks like it's an ISO8601 date format, which is used in web development, so I'm assuming you've downloaded this data from somewhere?
I've developed date parsing algorithms before and with proper testing you can build something quite robust, quite quickly. What you can do then is convert your NSDate's into strings and then feed those strings into your fetch predicates.
Related
I'm trying to write a schema for an ActiveRecord object.
I've decided to use iso8601 format throughout my application, including for external api requests.
Should the column be a string or datetime?
Is there any performance impact or distinction between the two?
Storing the date in the database as a date or datetime means you can use the date functions like comparing dates in the database. And it gives you the freedom to present the date in whichever format you choose, making it easy to do so if the formatting requirements change in the future, without having to touch the database.
Whereas storing the date in the database as a string removes all these advantages. You no longer can use database date functions. Plus, If you decide to use another format (maybe in a newer version of the API or for mobile apps... etc), you will need to parse the string back into a date/datetime object, which is not very appealing to do.
As a general good practice: the way you store data should be agnostic to the way you present it, when possible.
I am building a lucene query for an indexed object to determine if current time lies between the range of start Time and end Time. I'm unable to get the exact lucene query .
org.apache.lucene.search.Query luceneQuery5=queryBuilder3.bool()
.must(queryBuilder3.keyword().onFields("TimeDependentProfileKey").matching("TimeKey").createQuery())
.must(queryBuilder3.range().onField("StartTime").above(new Time(0)).createQuery())
.must(queryBuilder3.range().onField("StopTime").below(new Time(0)).createQuery()).createQuery();`
The lucene query which was generated looks like:
+TimeDependentProfileKey:3 +StartTime:[19700101000000000 TO *] +StopTime:[* TO 19700101000000000]
how do i change the format of timestamp, can anyone please help me.
By searching for a date object, you are deferring formatting to hibernate. I would consider the format you specified as functional, though perhaps not ideal. If you want to use your own formatting, you must deal in strings, be consistent in your formatting, and make sure your format will work well for sorting and range queries as a string.
If you want to have hibernate handle formatting dates for you, you need to define your date field with a #DateBridge(resolution = ...) annotation. This ensures that hibernate will format dates effective for correct range querying and sorting in lucene, and allows you to query against the field with date objects instead of strings.
I have a lot of different date format that one of my field can contain. And I'm trying to parse it but it some times doesn't understand the format at all and returns 1900-01-01.
Or sometimes, it invert months, days and year: 2023-12-11 instead of 2012-11-23.
The field is contained in a total of 1500-2500 excel files, that are produced by some kind of scanner. Dates and time are in different cases.
I've seen different formats such as these so far:
yyyy-mm-dd or mm/dd/yy and some others (that i cant find because i dont want to spend the day oppenning random excel files hoping to find a different format ^^')
So... I've tried parsing it at hand (Substring of the different fields), but it still has bugs, so:
Is there any date parsing tool for VB that works often?
I imagine there is a library or something that can parse dates from almost any format already coded, and if I could avoid to recode it I'd be quite happy :)
No, of course there is nothing that can parse dates in any (unknown) format. How should it know what to do with 9/10/11? That can be anything.
So you can use TryParse or TryParseExact (you can even pass a string[] for multiple allowed formats) and pass the correct CultureInfo.
Here is my problem. the date that i got from my database contains "12/31/2013". Based on this date, the format is mm/dd/yy. Now the question is how do i makes it that no matter what format of the date in the user's computer, they will always read the date "12/31/2013" as mm/dd/yy instead of example dd/mm/yy which when it reads it contains an error due to there is no 31 month. i try the split method on the date i receive from my database but i coudn't get it to confirm to the format that is independent from the user's computer
Is your date being stored in your database as an actual date format, or as a string?
Remember that DateTime.Parse by default, uses the current user's current system date/time formatting settings (so UK users are dd/MM/yyyy, but US users are MM/dd/yyyy). If you want uniform parsing then use DateTime.ParseExact and specify an exact parsing format string.
One rule of thumb that's useful to remember is that "if you're ever using String.Split, you're probably doing something wrong" (I'll make exceptions for quick-and-dirty by-design programs, but for parsing a Format-string, Regular-expression, or Finite state machine is more performant (less string allocations) and less brittle.
Back on-topic, if your database is storing objects as a date or datetime then don't use strings at all. Use the .GetDateString(int) method of IDataReader or typed field properties of EF classes.
How did you get a date from your database? Did you store the date as a string? If at all possible, consider keeping the date as a DateTime variable rather than a string. If not possible, look into the DateTime.TryParse method which supports internationalization and should be able to understand with the user's UI localization settings.
Its not clear if you want to read the same format from the database or display it on the screen (UI)
If its from the sql server, consider using convert <- follow this link
Does SQLs built-in DateTime type has any merits over nvarchar type?
If it were you , which one would you use?
I need to store dates in my SQLServer database and I'm curious to know which one is better and why it is better.
I also want to know what happens if I for example store dates as string literals (I mean nvarchar )? Does it take longer to be searched? Or they are the same in terms of performance ?
And for the last question. How can I send a date from my c# application to the sql field of tye DateTime? Is it any different from the c#s DateTime ?
You're given a date datetype for a reason, why would you not use it?
What happens when you store "3/2/2012" in a text field? Is it March 2nd? Is it February 3rd?
Store the date in a date or datetime field, and do any formatting of the date after the fact.
EDIT
If you have to store dates like 1391/7/1, your choices are:
Assuming you're using SQL Server 2008 or greater, use the datetime2 data type; it allows dates earlier than 1753/01/01 (which is what datetime stops at).
Assuming you're using SQL Server 2005 or earlier, store the dates as Roman calendar dates, and then in your application, use date/time functions to convert the date and time to the Farsi calendar.
Use the correct datatype (date/datetime/datetime2 dependant on version and requirement for time component).
Advantages are more compact storage than storing as a string (especially nvarchar as this is double byte). Built in validation against invalid dates such as 30 February. Sorts correctly. Avoids the need to cast it back to the correct datatype anyway when using date functions on it.
If I'm storing a DateTime value, and I expect to perform date-based calculcations based on it, I'll use a DateTime.
Storing Dates as strings (varchars) introduces a variety of logistical issues, not the least of which is rendering the date in a proper format. Again, that bows in favor of DateTime.
I would go with the DateTime since you can use various functions on it directly.
string wouldn't be too much of a hassle but you will have to cast the data each time you want to do something with it.
There is no real performance variance while searching on both type of fields so going with DateTime is better than strings when working with date values.
you must realise the datetime datatype like other datatypes is provided for a reason and you should use the datatype that represents your data clearly.. Besides this you gain all the functionalities/operations that are special to the datetime datatype..
One of the biggest gains is correct sorting of data which will not be possible directly if you use nvarchar as your datatype.. Even if you think you dont need sorting right now there will be a time in the future where this will be useful.
Also date validation is something that you will benefit from. There is no confusion of the dateformat stored i.e dd/mm or mm/dd etc..
There is lot discussed about the subject. There is good post on the SQLCentral forum about this particular subject DateTime or nvarchar.
In short, nvarchar is twice as longer as datetime, so it takes more space and on the long range, any action affecting it will be slower. You will have some validation issues and many more.