If a butterfly flaps its wings in the Amazon could it cause rain in Africa? One bit or stack modified way over there could start the dominoes falling. Why do you think it takes so long for some bug fixes to be released? Fix a bug over here and it causes another bug over there sometimes.
Software engineering isn't chaotic in the mathematical sense, and a bug in a higher level component does not propagate to other higher level components. If the Apple API ( NSDate) is faulty then it would manifest in other components and higher level functions like the clock and reminders etc.
We measure a "year" according to the duration of the earth making a complete orbit of the sun and that duration is slowing down (albeit minutely), therefore we measure that duration in "days." However, "days" are measured by the duration of the earth making one complete rotation on its axis and that rotation is slowing down as well. Therefore we measure our days in seconds. We have been adding "leap seconds" and "leap days" when required to keep our measurement of time in allignment with the position of the earth in relation to the sun (while largely neglecting lunar events at all).
All this adjustment is really to keep the peasants (read: all of us) happy and not confuse us about what "time" it is. I wish we could move off the current calendar that was inspired in BCE and move to a more accurate and modern device.
I feel bad for the software engineers that have to write code that recalls all the colloquial names we have for the time we keep.
This is bullshit... Apple and their: "you're holding it wrong", "the previous clock bug", and this new bug that we have to wait until the 7th. They didn't have to wait to get my money... This is simply crappy, shoddy work... I like Apple but this is crap...
So what the hell do you want Apple to do? They obviously know this is an issue, but why try to create a quick fix and "hope" everyone installs the update before the 7th? Did anyone ever state that Apple was a perfect company? The bigger crap is your response to something that really isn't a big deal and fixes itself in less than a week.
You want to see stupid little issues...go buy an Android phone and you'll get plenty of them. I've been there done that with 2 Android phones.
Software engineering isn't chaotic in the mathematical sense, and a bug in a higher level component does not propagate to other higher level components. If the Apple API ( NSDate) is faulty then it would manifest in other components and higher level functions like the clock and reminders etc.
NSDate is pretty archaic in its logic but I've never experienced any bugs with it. I agree with you - why is only Apple experiencing yearly date bugs and not third party developers?
I wonder how it's gonna fix itself on 7-th of January. But what if it won't, what then Apple is going to say?
Obviously, they know exactly what's causing it, and they know it's going to stop being a problem on that date.
It's easy to test by putting the phone into airplane mode and manually setting the time, and Apple appear to be correct. Up until Monday, Jan 7 2013 the do not disturb mode does not switch off at the scheduled time, but starting on Jan 7 it begins to behave correctly again.
However, next year the bug reappears, and corrects on Monday, Jan 6, 2014. Must be something to do with the first Monday in January. Presumably they expect to fix it with an update before then.
To the best of my understand this bug is caused by 2012 being a leap year.
Basically how many pieces of software keep track of daily schedules is by knowing what week of the year it is. So since we had a leap year we had an extra day which meant on Monday technically it was week 53 of 2012. And Tuesday was week 0 of 2013.
Next Monday would start a new week thus having an actual week number and fixing the issue.
To the best of my understand this bug is caused by 2012 being a leap year.
Basically how many pieces of software keep track of daily schedules is by knowing what week of the year it is. So since we had a leap year we had an extra day which meant on Monday technically it was week 53 of 2012. And Tuesday was week 0 of 2013.
Next Monday would start a new week thus having an actual week number and fixing the issue.
Except that doesn't explain why it reappears in 2014. And when it is based on time of day, why does it care about the week number?
To the best of my understand this bug is caused by 2012 being a leap year.
Basically how many pieces of software keep track of daily schedules is by knowing what week of the year it is. So since we had a leap year we had an extra day which meant on Monday technically it was week 53 of 2012. And Tuesday was week 0 of 2013.
Next Monday would start a new week thus having an actual week number and fixing the issue.
Its a relief that everyone else is facing this problem, not just me. How much has Scott forstall screwed up iOS? Apple still cant their iOS issues fixed. Looks like the most advanced mobile operating system that was 5 years ahead has started doing catch up by going backwards.. It is actually funny that such a simple feature was not done right. I guess time to forgive Apple for their Apple maps fiasco.. Hilarious.
I imagine that this was meant tongue-in-cheek, but the fact is that robust date libraries are readily available and, no doubt, used by other portions of iOS.
The common cause of these issues are new/naive coders who aren't aware of the libraries they should be using, and thus try to do the calculations themselves (and, almost universally, incorrectly).
You don't think that all code changes are vetted by at least two programmers and testing is done? You seem to have a negative view on programmers in general.
i do know the API - the API is public. And I know more than you.
You saw their code? So, no, you don't know any more than I do. Less actually, since I at least know you have no idea what you are talking about and you don't.
Comments
Quote:
Originally Posted by asdasd
Most coders could do better.
I sincerely doubt it.
Well you don't know much. The low level API handle this, the bug is very very odd.
Software engineering isn't chaotic in the mathematical sense, and a bug in a higher level component does not propagate to other higher level components. If the Apple API ( NSDate) is faulty then it would manifest in other components and higher level functions like the clock and reminders etc.
Quote:
Originally Posted by sapporobabyrtrns
I like Apple but this is crap...
ROTT violation, Rule 4: http://forums.appleinsider.com/t/152839/rules-of-the-troll-wip#post_2197164
Poster at risk of random banning.
Quote:
Originally Posted by asdasd
Well you don't know much. The low level API handle this, the bug is very very odd.
Like you know anything about it. Stop pretending you know what you are talking about.
We measure a "year" according to the duration of the earth making a complete orbit of the sun and that duration is slowing down (albeit minutely), therefore we measure that duration in "days." However, "days" are measured by the duration of the earth making one complete rotation on its axis and that rotation is slowing down as well. Therefore we measure our days in seconds. We have been adding "leap seconds" and "leap days" when required to keep our measurement of time in allignment with the position of the earth in relation to the sun (while largely neglecting lunar events at all).
All this adjustment is really to keep the peasants (read: all of us) happy and not confuse us about what "time" it is. I wish we could move off the current calendar that was inspired in BCE and move to a more accurate and modern device.
I feel bad for the software engineers that have to write code that recalls all the colloquial names we have for the time we keep.
Quote:
Originally Posted by greybeard
I wonder how it's gonna fix itself on 7-th of January. But what if it won't, what then Apple is going to say?
Obviously, they know exactly what's causing it, and they know it's going to stop being a problem on that date.
Quote:
Originally Posted by sapporobabyrtrns
This is bullshit... Apple and their: "you're holding it wrong", "the previous clock bug", and this new bug that we have to wait until the 7th. They didn't have to wait to get my money... This is simply crappy, shoddy work... I like Apple but this is crap...
So what the hell do you want Apple to do? They obviously know this is an issue, but why try to create a quick fix and "hope" everyone installs the update before the 7th? Did anyone ever state that Apple was a perfect company? The bigger crap is your response to something that really isn't a big deal and fixes itself in less than a week.
You want to see stupid little issues...go buy an Android phone and you'll get plenty of them. I've been there done that with 2 Android phones.
Quote:
Originally Posted by asdasd
Software engineering isn't chaotic in the mathematical sense, and a bug in a higher level component does not propagate to other higher level components. If the Apple API ( NSDate) is faulty then it would manifest in other components and higher level functions like the clock and reminders etc.
NSDate is pretty archaic in its logic but I've never experienced any bugs with it. I agree with you - why is only Apple experiencing yearly date bugs and not third party developers?
It's an odd situation.
Quote:
Originally Posted by anonymouse
Like you know anything about it. Stop pretending you know what you are talking about.
i do know the API - the API is public. And I know more than you.
Quote:
Originally Posted by anonymouse
Quote:
Originally Posted by greybeard
I wonder how it's gonna fix itself on 7-th of January. But what if it won't, what then Apple is going to say?
Obviously, they know exactly what's causing it, and they know it's going to stop being a problem on that date.
It's easy to test by putting the phone into airplane mode and manually setting the time, and Apple appear to be correct. Up until Monday, Jan 7 2013 the do not disturb mode does not switch off at the scheduled time, but starting on Jan 7 it begins to behave correctly again.
However, next year the bug reappears, and corrects on Monday, Jan 6, 2014. Must be something to do with the first Monday in January. Presumably they expect to fix it with an update before then.
To the best of my understand this bug is caused by 2012 being a leap year.
Basically how many pieces of software keep track of daily schedules is by knowing what week of the year it is. So since we had a leap year we had an extra day which meant on Monday technically it was week 53 of 2012. And Tuesday was week 0 of 2013.
Next Monday would start a new week thus having an actual week number and fixing the issue.
Quote:
Originally Posted by shadrian
Quote:
Originally Posted by einsteinbqat
I wonder what causes this bug.
To the best of my understand this bug is caused by 2012 being a leap year.
Basically how many pieces of software keep track of daily schedules is by knowing what week of the year it is. So since we had a leap year we had an extra day which meant on Monday technically it was week 53 of 2012. And Tuesday was week 0 of 2013.
Next Monday would start a new week thus having an actual week number and fixing the issue.
Except that doesn't explain why it reappears in 2014. And when it is based on time of day, why does it care about the week number?
Quote:
Originally Posted by igxqrrl
I imagine that this was meant tongue-in-cheek, but the fact is that robust date libraries are readily available and, no doubt, used by other portions of iOS.
The common cause of these issues are new/naive coders who aren't aware of the libraries they should be using, and thus try to do the calculations themselves (and, almost universally, incorrectly).
You don't think that all code changes are vetted by at least two programmers and testing is done? You seem to have a negative view on programmers in general.
Quote:
Originally Posted by asdasd
i do know the API - the API is public. And I know more than you.
You saw their code? So, no, you don't know any more than I do. Less actually, since I at least know you have no idea what you are talking about and you don't.