From the story, I infer that you're coding on your own.
Normally the purpose of BDD is to enable conversations, particularly between the business and the developers, so that the team can be sure they've reached a common understanding. We also like to include testers, because they can spot when we've missed scenarios.
If you're doing this on your own, grab a rubber duck and explain the behavior of your application to the duck. Give some examples of how it should work. Those will be your scenarios.
To start with, I would suggest not automating those scenarios. You can write them down if you like. Remember that the business outcomes that you shared with the duck are about the right level to phrase them in. You should now have an idea of how the app behaves, and you can run through the scenarios manually. I like to treat everything that doesn't work yet like a bug. I have sometimes started with automation, but only when I know very well how the system works, I'm familiar with the tools, and the UI is well understood. Even then I often have to rework it a bit when I've written the code.
At a lower level, tell your duck how each class is going to behave. Provide some examples. Rubber ducks are perfectly capable of understanding technical language. Now you have your unit-level BDD, aka unit tests. The red-green-refactor cycle happens here. (I don't tend to need to refactor so much any more, because I'm thinking about the responsibilities of my classes, phrasing it in business-oriented language, and it tends to fall out in quite a beautiful way anyway. But I've been doing this for a while now. It's OK if you do.)
Don't refactor it too much. We still want to get feedback on our code, because there's always things we don't know that we don't know. Perfection is your enemy here. Make it good enough, make it readable, then move on. If you need to make something perfect to make further changes, do it when you make further changes.
If you have the opportunity to get feedback on your scenarios from business stakeholders, but they're not sat with you, you can send scenarios to them as soon as you've written then, and before you automate them. You might want to send a mock-up of the UI, too, so that they can correlate words to actions. Don't get too far ahead of the coding with this. Work with the assumption that what you've already done is wrong, and you need to get feedback to find out how.
As one final hint, don't generally phrase stories from a user's point of view (scenarios, yes, but not stories). They're not user stories. It should probably read something like:
In order to attract people to my website
As @thom
I want users to easily convert months and days to days.
There's some higher level goal you're looking for, anyway. This will also help you draw out the capabilities you need. Good luck with it, and apologies for the extra-long post.
