Is it possible to perform date calculations with a 2-digit year, such as, mm/dd/yy? Or is that not advisable for some reason?
For example, all my date formats say [dateFormat setDateFormat:#"mm/dd/yyyy"];. Can I change this to [dateFormat setDateFormat:#"mm/dd/yy"]; or would there be any unforeseen consequences when performing date calculations?
Thanks!
I think you should always respect the current culture settings of the end user. But perhaps you have a special program where you are parsing or generating external files that must use a specific format, for example a log file or a DBase file, yes then giving a specific format is useful.
Date calculations should be done with NSDate instances which are independent of the date format. The format is only used when converting to and from a string for input and output. The formatting is done as per the Data Formatting Guide
Yes You Can use it. try following code.
NSDateFormatter *dateformate=[[NSDateFormatter alloc]init];
[dateformate setDateFormat:#"MM/dd/YY"];
NSString *date_String=[dateformate stringFromDate:[NSDate date]];
NSLog(#"Today: %#", date_String);
Related
I'm trying to store a time in a date.
In this case 1.5 seconds.
I store the time in the date like this:
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:#"mm:ss.SS"];
[dateFormatter setTimeZone:[NSTimeZone timeZoneForSecondsFromGMT:0.0]];
NSDate *date1 = [dateFormatter dateFromString:#"00:01.50"];
But if I look in the debug area I can see that the value of date1 was set to:
date1 = (NSDate *) 0x1dd32b30 2000-01-01 01:00:01 CET
Could anyone tell me why this is happening?
Because there is a mass of question related to NSDate on SO and they all have the same shade, I will give you a longer answer, probably this can be referred from other questions.
A. There is a common misunderstanding, what a date is: A date is a point on timeline. It does not deal with hours or minutes, it does not deal with days, month, years, it does not deal with timezones.
It is a point on a timeline. Period.
(And internally it is represented by an floating-point number. Is that a surprise?)
B. There is another common misunderstanding, what a date is: Two dates, therefore points on a timeline, are equal, if the have the same value. This does not mean, that they have the same representation. Two times can be equal, even their representation is completly different. (This is, what happened to you.) For a comparison it does not matter, which timezone is in use, expected, $whatever. For a comparison is does not matter, which calendar is in use, expected or $whatever. If it is 11:11 in Cologne, Germany (UTC+1) it is 10:11 in London, England (UTC+0). This is the same time.
A date is earlier if it is on the timeline ahead of another date.
C. So what are these funny things like days, month, timezones and so on?
Since outside a star trek episode a time like 26,182,382,303.127373 would be difficult to understand and to handle, human beings began to give points on the timeline funny names. This representations are not the date. They are representations of the date. It is the same problem with numbers. Do you no this joke?
"There are 10 kind of people: Those, who understand binary numbers and those who doesn't."
The spirit of the joke is, that 10 can be the value of ten, if it is written in decimal notation or it can be the value of two, written in binary notation. Nobody can say, what value "10" denotes unless he knows the numeral system which is used for the representation. Most people assume, that it is in a decimal system, so "10" means ten. This is a popular convention. And this works fine since nearly all over the world adopted that convention. But: "10" can denote two different values. And the other way around, too: The same value can be written with different "strings": 10 in decimal notation is equal to 1010 in binary notation (and is equal to "2+8", sqrt(100), … That is, why it is allowed to write = between them.)
Unfortunaly (no, not really, time has to work locally in an easy way) for time there is no world-wide convention. If somebody writes "11:11" you simply cannot say, what time (remember, it is a point on the timeline) is meant. Probably the person implicitly says, that this is the time in his calendaric system in his timezone. But then you have to know, at which location on the world he is saying that. Taking day, month and so on in account, you probably have to know, what is his religion, because even in one country people of different religions uses different calendars.
Since there is no common world-wide convention on one hand and Mac OS is running on computer systems world-wide, you cannot assume, that a time printed out is written in a notation you expect.
Therefore it is completly, eh, not very intelligent to compare to dates by string. You do not compare dates, you compare strings.
Before you compare a time (including date) you have to transform the representation to a time to the "real" time. You have to add information about the calendar, the representation is written in and the timezone (which is included in the calendar in Cocoa).
In Cocoa you use instances of NSDateFormatter, NSCalendar, NSDateComponents to do this job. If you let NSDateFormatter transform a representation to a time and vice versa, you have to set the calendar. (NSDateFormatter assumes, that the local calendar is choosen, if you do not set one.) It is simply impossible to NSDateFormatter to do any transformation work, if it does not know which calendar to use. And it is simply impossible for you.
Then you can do some calculations with it, the date, the time, the instance of NSDate, including comparison and at least you have to transform it back into a human-readable representation using a calendar.
What you get and let you think, that it is a wrong time, is simply the correct time but in a represenatation you did not expect. (-description always delivers UTC+0).
Trying NSLog on date will return date in GMT format only. So if you want to check if you are getting the correct time or date, convert date to string and NSLog.
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:#"mm:ss.SS"];
[dateFormatter setTimeZone:[NSTimeZone timeZoneForSecondsFromGMT:0.0]];
NSDate *date1 = [dateFormatter dateFromString:#"00:01.50"];
NSString *dateString = [dateFormatter stringFromDate:date1];
NSlog(#"%#",dateString);
This question already has answers here:
Converting an ISO 8601 timestamp into an NSDate: How does one deal with the UTC time offset?
(6 answers)
Closed 9 years ago.
I have tried and tried and researched and tried again but I cannot format this
The date is:
"2013-08-08T11:10:09-07:00"
I've tried using "yyyy'-'MM'-'DD'T'HH':'mm':'ssZ" and a host of different permutations of this but to no avail. I think perhaps the server is sending the incorrect format of the timezone.
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:#"yyyy'-'MM'-'DD'T'HH':'mm':'ssZ"];
return [dateFormatter dateFromString:[dictionary objectForKey:key]];
Any clues?
Thanks in advance
For the non-localized ISO offset that you're using—e.g., -07:00—you need to use 5 Z characters in your format. So, for the source data given, the correct format string would be:
yyyy-MM-dd'T'HH:mm:ssZZZZZ
While the currently used technical standard doesn't require date and time separators to be escaped, as Jeff mentions in the comments, it's probably not a bad idea to do so, especially if your source date is coming from a server or something. There are discussions on making those replacements, like the letters, that would change for locale-specific date and time separators. It also doesn't hurt to escape them from a technical perspective, it's just harder to read:
yyyy'-'MM'-'dd'T'HH':'mm':'ssZZZZZ
For more information, the current date formatter is based on the Unicode Technical Spec #35. The date and time pattern specifications for #35 can be found at http://www.unicode.org/reports/tr35/tr35-25.html#Date_Format_Patterns
I'm trying to store a time in a date.
In this case 1.5 seconds.
I store the time in the date like this:
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:#"mm:ss.SS"];
[dateFormatter setTimeZone:[NSTimeZone timeZoneForSecondsFromGMT:0.0]];
NSDate *date1 = [dateFormatter dateFromString:#"00:01.50"];
But if I look in the debug area I can see that the value of date1 was set to:
date1 = (NSDate *) 0x1dd32b30 2000-01-01 01:00:01 CET
Could anyone tell me why this is happening?
Because there is a mass of question related to NSDate on SO and they all have the same shade, I will give you a longer answer, probably this can be referred from other questions.
A. There is a common misunderstanding, what a date is: A date is a point on timeline. It does not deal with hours or minutes, it does not deal with days, month, years, it does not deal with timezones.
It is a point on a timeline. Period.
(And internally it is represented by an floating-point number. Is that a surprise?)
B. There is another common misunderstanding, what a date is: Two dates, therefore points on a timeline, are equal, if the have the same value. This does not mean, that they have the same representation. Two times can be equal, even their representation is completly different. (This is, what happened to you.) For a comparison it does not matter, which timezone is in use, expected, $whatever. For a comparison is does not matter, which calendar is in use, expected or $whatever. If it is 11:11 in Cologne, Germany (UTC+1) it is 10:11 in London, England (UTC+0). This is the same time.
A date is earlier if it is on the timeline ahead of another date.
C. So what are these funny things like days, month, timezones and so on?
Since outside a star trek episode a time like 26,182,382,303.127373 would be difficult to understand and to handle, human beings began to give points on the timeline funny names. This representations are not the date. They are representations of the date. It is the same problem with numbers. Do you no this joke?
"There are 10 kind of people: Those, who understand binary numbers and those who doesn't."
The spirit of the joke is, that 10 can be the value of ten, if it is written in decimal notation or it can be the value of two, written in binary notation. Nobody can say, what value "10" denotes unless he knows the numeral system which is used for the representation. Most people assume, that it is in a decimal system, so "10" means ten. This is a popular convention. And this works fine since nearly all over the world adopted that convention. But: "10" can denote two different values. And the other way around, too: The same value can be written with different "strings": 10 in decimal notation is equal to 1010 in binary notation (and is equal to "2+8", sqrt(100), … That is, why it is allowed to write = between them.)
Unfortunaly (no, not really, time has to work locally in an easy way) for time there is no world-wide convention. If somebody writes "11:11" you simply cannot say, what time (remember, it is a point on the timeline) is meant. Probably the person implicitly says, that this is the time in his calendaric system in his timezone. But then you have to know, at which location on the world he is saying that. Taking day, month and so on in account, you probably have to know, what is his religion, because even in one country people of different religions uses different calendars.
Since there is no common world-wide convention on one hand and Mac OS is running on computer systems world-wide, you cannot assume, that a time printed out is written in a notation you expect.
Therefore it is completly, eh, not very intelligent to compare to dates by string. You do not compare dates, you compare strings.
Before you compare a time (including date) you have to transform the representation to a time to the "real" time. You have to add information about the calendar, the representation is written in and the timezone (which is included in the calendar in Cocoa).
In Cocoa you use instances of NSDateFormatter, NSCalendar, NSDateComponents to do this job. If you let NSDateFormatter transform a representation to a time and vice versa, you have to set the calendar. (NSDateFormatter assumes, that the local calendar is choosen, if you do not set one.) It is simply impossible to NSDateFormatter to do any transformation work, if it does not know which calendar to use. And it is simply impossible for you.
Then you can do some calculations with it, the date, the time, the instance of NSDate, including comparison and at least you have to transform it back into a human-readable representation using a calendar.
What you get and let you think, that it is a wrong time, is simply the correct time but in a represenatation you did not expect. (-description always delivers UTC+0).
Trying NSLog on date will return date in GMT format only. So if you want to check if you are getting the correct time or date, convert date to string and NSLog.
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:#"mm:ss.SS"];
[dateFormatter setTimeZone:[NSTimeZone timeZoneForSecondsFromGMT:0.0]];
NSDate *date1 = [dateFormatter dateFromString:#"00:01.50"];
NSString *dateString = [dateFormatter stringFromDate:date1];
NSlog(#"%#",dateString);
I have a strange problem with parsing date string. I have a date formatter with format:
yyyy-MM-dd HH:mm:ss.SSSSSSZZ
and date string:
2012-11-09 10:47:01.999804+01
dateFromString method returns nil, but when I change date string to ie:
2012-11-09 10:47:01.989804+01
it works... Does anyone has idea why there is such limit for microseconds value and how can I properly parse dates like the one above?
I could parse that with regex and cut whole SSSSSS part, but generally sometimes I will need to compare dates so they would not be matching and it will cause more problems.
I had no end of niggly issues doing this, finally got it to work but stripped the point seconds off and used the format as follows
#define DATEFORMATSTRINGTIMEZONE #"yyyy-MM-dd HH:mm ZZZ"
a bit like you say. I have to admit a bit more into the project I realized this was a very difficult method of sharing dates and instead adopted epoch time which has saved all headaches I was having regarding timezones... I'd highly recommend it if you have the luxury of changing the incoming data format.
Whilst I'm not sure why yours doesn't parse, I would question the ZZ instead of the ZZZ at the end given you have +01 not +1?
I have finally resolved that issue.
I'm modifying date format and date string to remove microseconds so I can parse date properly. Then I just add microseconds parsed from original date string.
I have a basic calculator app and it doesn't handle percentages properly in regions where a decimal point "." is used as the comma separator and a comma "," is used to mark the radix point. I am working on a fix for this but in the meantime I am wondering if when my app launches, I could override the Region Format set in the devices settings app and force a specific Region Format, only for my app.
Is this possible? Thank you for your time with this.
Instead of doing this, I suggest you look at NSNumberFormatter and NSNumber to do it the right away. For example, this should work regardless of the device's regional settings.
NSNumberFormatter *formatter = [[NSNumberFormatter alloc] init];
[formatter setNumberStyle:NSNumberFormatterDecimalStyle];
NSNumber *test = [formatter numberFromString:#"1,000,000"];
Also look at the other functionality provided by NSNumberFormatter. This seems like a more elegant way to do it than what you're trying.