D/a/y home

What is D/a/y?

Essentially an API describing how rich dates are used

Days are objects that superficially look like dates but allow for missing parts. For example '1956', 'Jan 2011' could be valid.
The rules for comparison and manipulation need careful definition.
Also the methods for manipulating dates are closely defined. For example '31 Jan 2013' plus '1 month' is '28 February 2013'.
And what is '28 Feb' minus one month? This changes on a leap year.
Furthermore there are no worries about UNIX epoch roll-over or Javascript limitations.
Mostly dealt with now but there are gotchas.
The semantics of missing or vague data is clearly defined. For example there's a big difference between Not known and Not valid.
We conveniently supply Today, Beginning of time and End of time. B and E are important concepts for input and processing.
Internationalisation is built-in.
It is straightforward to switch locales and tweak common usage parameters like default day-month (or month-day) order. Most input errors are automatically translated or can be called from a template using a vocabulary.
Day is also shipped with a front-end helper which greatly simplifies coding user interfaces.

In short, D/a/y deals with dates like humans do in real-world situations, without trying to turn everything in to a timestamp. What is 31st January plus 1 month? Does May 10th come before or after May (Answer:During) How do I input 'Not yet' or 'before we started counting'.

Come on! Come ON! When did you buy your car? I must have YEAR MONTH AND DAY how simple is that! Are you STUPID?

Can you recall the exact day you bought your car? (I can just about guess the month.) What if you're in the middle of trading cars and don't actually have one? Or you're getting it delivered some time next week? This illustrates a typical UI failure. And the back-end won't know how to deal with dates without days either. What a shambles!

Why bother with D/a/y?

Because it's a lot better at dealing with all date-related issues than what are essentially timestamps.

Partial dates are a common real-world requirement.
2012 is not 1 Jan 2012 You've all seen something like How many years have you held a driving license? If the system does any sums with this then it needs to work to yearly precision not daily.
In Day a date is not a second but anywhere between 24 hours and 366 days.
Missing or vague dates are a common real world requirement.
Don't know is not 1 Jan 1900

Period of illness: to What goes in here if you're still ill?
(And how does the system show it?) (And how does the system do calculations?)
From user, through to database, out to external systems and internal calculations Day, deals these issues.
How do you adapt your UI for different locales?
Day is locale-ready
Do you hand-code your date interactions in the browser? Eeek!
Use the form-helper library to greatly simplify common tasks.
Do your system's rules for dealing with uncertain dates or leap years or adding one month match somebody elses?
You can't simply subtract two dates to get the difference. Whats 17 March 2015 'minus' March 2000?
Day implements a documented standard for fudging and interpreting date operations.

How can I...

See it in action	See the demonstrations on this site. These demonstrations are quite useful as a guide to understanding what sort of date issues lurk in systems and how you might deal with them.
Have a go	Download and code. There is plenty of documentation to get you started.
Trust the code	Download the test suite and run it for yourself.
Contribute	This project needs two sorts of contributions. General skilled manpower to maintain the code and documentation and packages in tip-top condition. Internationalisation appendices.
Adapt it	This is not a free-for-all project. There is a standard suite of tests and we put code quality before the excitement of half-hour developers. If you find an issue, develop a fix or a feature then please go to the Developer's forum