if you're writing tests, you should aim for corner cases. for date-based applications that would include the first and last days in the year, leap years, etc.
programming can be a bit less hard if you learn to do it right.
Calendar-based stuff is absurdly difficult to get right. Even if you have something that seems to work you likely have a hidden error somewhere. That's not really an excuse -- edge conditions like DST on/off, and end-of-year should be first on your test list. But calendars suck to work with.
I find it fascinating that it doesn't work between 1/1/13 and 1/6/13 but claims it will start working on 1/7/13. What is different about the 7th than the 6th?
So that seems like they're doing some kind of math using the week of year in the calculation- but for what purpose? The UI doesn't seem to give you any options for day of week, just time of day.
Maybe there's code in there that checks day of week but it's hardcoded to run every day to make the UI simpler.
So maybe the service updates it's schedule weekly but the calculation ignores the year. This throws up an error at New Year's and borks the code that would reset when it's toggled on/off?
Oh yes. The ISO definition is pretty straightforward: «The first week of a year is the week that contains the first Thursday of the year.» (http://en.wikipedia.org/wiki/ISO_week_date)
In my case I had a date that I needed to parse from JSON. It was in this format: 2012-01-21. I parsed it using YYYY-MM-dd. It should have been yyyy-MM-dd for the reasons above.
It is not technically a bug but it real easy to get wrong. Perhaps they should have picked sometimg other than YYYY for week years.
I have a hard time (ow) having much anger over time-related bugs these days. Seems the only real way of getting the calendar more programmer-friendly is to switch the world over to Unix time.
I'm amazed by how many applications don't do this (and, similarly, how many languages make it difficult just to get a simple UNIX timestamp). It's far and away the easiest medium to work with, even if you only use it as a pivot format[1].
I imagine many things use Unix time or a similarly flat calendar internally (Twitter's Snowflake[0] uses a custom scale), it's the translation into the Gregorian (/Jewish/Mayan/etc) calendar and time scale where the bugs come from. Can't count on 31540000 seconds being a year, time zones, etc.
At the same time, the human brain doesn't seem particularly well-suited to breaking down Unix time into meaningful and reliably consistent scales, so I don't see time getting much easier barring some revolutionary timekeeping system.
Off the top of my head, it's easier to think of APIs that don't provide UNIX timestamps than ones that do. You wouldn't believe some of the half-baked implementations I've seen used in production code (unless you've also had to deal with it yourself, that is!)
Yes, you still have to deal with timezones, but I'd much rather be given a UNIX timestamp for a UTC time and then adjust accordingly, rather than deal with all the other problems that come from communicating and converting between various other calendar formats and locales.
And this exchange should occur at the very last step, only when being displayed to the user. For almost any other purposes, there's no reason that two different applications should need to talk to each other using anything but UNIX timestamps. The potentially error-prone conversion should happen in the latest stage possible, because that's the part with the most knowledge of how any error should be corrected.
> At the same time, the human brain doesn't seem particularly well-suited to breaking down Unix time into meaningful scales,
But we're talking about for programming purposes - to a computer, one 64-bit int is as good as any other.
No, it is possible to convert between some time formats. For example, if I invented a new time format that actually was "number of seconds since midnight 1/1/1970" then you could actually convert 1:1 between it and UTC.
It's just that you can't do it with some formats, like UTC - Unix time or UTC - (only include the last 2 digits of the year like in Y2K)
My point is that there's no one format that's going to have seamless conversion with everything that various applications need, but the UNIX timestamp still makes for the best intermediary by far.
There's a difference between "This is not a great time format for conversions" and "This value in the format represents 2 possible different actual times and we have no idea how to tell them apart"
Instead of telling you about the worst one I've seen in an API implementation, I might as well just show you the code it took to turn it into a correct timestamp:
Well, no there are several good cases where storing a time in UTC as seconds since an epoch is wrong.
It's a common mistake.
The first usecase is Birthdays. For most purposes people do not want to store the extract time and date of their birthday in the original time zone. Apple do this, much to my annoyance - it means people's birthdays change as you move around our planet, and that doesn't align with how they work in the real world. If I'm born in Utah on 1/1/1980 it does not mean I celebrate my birthday on 31/12 when I'm in Australia.
The second usecase is recurring meetings, particularly with global participants. The mind bending case is where you have DST in some or all of the TZs. The only remotely correct thing you can do is keep the meeting at the same wall-clock time in the TZ of the meeting owner (9am meeting stays at 9am). Most apps don't, and there is no perfect answer (consider a participant in a different TZ - the meeting changes to a possibly conflicting time).
Sometimes storing the absolute time/date is correct. Other times storing the original UTC offset, as well as the time in UTC is. But most of the time, yes, store it in UTC in whatever form you prefer.
But then we need to do something special for leap seconds. Despite what lots of people think, Unix time is not the number of seconds since 1st Jan 1970, since it doesn't include the 30ish leap seconds that have been added since then.
To be clear: It's not the "correct" wall clock time for most people's day to day use, because it only counts seconds that have elapsed since 1st Jan 1970 00:00 (in a continuous unbroken manner), and does not count leap seconds (which are added to keep our daily-use times in sync with the rotation of the earth.) Isn't time fun?
Reminds me of the Zune leap year bug that got some press four years ago [1]. A Zune running during 11:59 PM, Dec 31, 2008 would freeze when the clock ticked over to Jan 1.
Even the response to the problem is similar. Microsoft says, wait until the 2nd and the problem will resolve itself. Apple says, wait until the 7th and the problem will resolve itself.
Calendar/time stuff is really, really hard. That's not an excuse for Apple in particular, just that the pitfalls are many and varied to the point where even smart people will screw it up.
I imagine one reason it doesn't seem so hard at first glance is because time and the calendar, in our lived experience, is relatively simple.
The biggest favor Apple could do their users is simply to provide a silent ringtone option, so that users can leave their ringer turned off while 'whitelisting' the appropriate contacts.
It's simply staggering that this has apparently never occurred to anyone at Apple. The cheapest feature phone in a bubble package at Radio Shack supports silent ringtones -- or at least it did a few years ago -- but with the iPhone, the user has to record or purchase a track with several seconds of silence and create one manually.
That is exactly what Do Not Disturb does. It allows for whitelisting of contacts, both specifically in the Contacts app, and if they are very persistent callers (emergency, urgent).
ooh ooh ooh. Disclaimer: Plug for my app called "tonepush" coming up.
I wrote an app that allows you to change the ringtone on someone else's phone (think xmas tunes, valentine songs etc etc). Anyway, one of my users had this issue where his wife is expecting a kid and he always has his phone on silent at work, so I've extended the app so that if he enables a web password, she can log in, turn his phone off silent and then ring him.
Before you say it, no it's not for iPhone but for Android. It's called TonePush Beta. All feedback gratefully received.
Interestingly you can set a silent alert for text messages per contact. I have this for automated balance/credit/debit alerts from my banks as they seem to think everyone wants to know their balance at 7am.
Yeah, AT&T likes to sending texts to confirm my monthly payment at the ungodly hour of 2 PM. For some reason, these idiots assume that everybody works 9-5 and nobody works nights.
Could have been spun as a feature. Apple believes you should be on a break during this time of the year so DND stays on until the 7th. Because we believe in choice, you can still switch it off manually.
reply