Documentation pdf Introduction and specification

Model	32 bit representation	Methods	Interface	Developers
'Normal' calendar dates including precise and vague dates such as "June 2008" exist on a pseudo-timeline. Forward Backward 2007 1 Feb 2007 Jan 2007 Jan 2007 1 Jan 2007 31 Jan 2007 2 Jan 2007 30 Jan 2007 • • • • • • 31 Jan 2007 1 Jan 2007 Feb 2007 2006 1 Feb 2007 Dec 2006 This might seem a bit weird at first but it works as we do and it doesn't interfere with 'date arithmetic'. 'Floating dates' such as "14th" eg. monthly pay-day or "13th August" eg. when you receive lots of birthday cards are fully supported. 'Special markers' such as "End of time" ie. Some time in the future but details as yet unknown, "Not known", "Not valid", "Beginning of time" exist to deal with real-world situations.	A span of plus and minus four millennia A switchable UNIX timestamp compatibility mode Easily sorted Can be used for intervals. eg so many days, months and years	Traditional 'arithmetic' Varieties of "does date A come before date B?" and similar relations. With exact dates this is simple but what about "Does March 14th 2008 come before or after March 2008". (Answer neither, it is 'contained'.) If both job A and job B are scheduled to finish in May then what's the maximum period when only one will be in progress? We need a well defined API to give consistent results. How should non-dates be handled? When should we raise an exception and when return something like 'Not known' or 'Not valid'?	Support for internationalisation is built into the method specification. This allows programmer defined switching between locales Input, including short cut keys. Eg In English "T" would be an acceptable abbreviation for "Today". I18n tags provided for typical input messages such as, drop-down lists, help texts and error messages. Output formats are passed through i18n calls as appropriate. Download Test harness written in Delphi. (Win only.)	As of June 2009 these specifications exist 'on paper' in a lot of detail. The objective is to have libraries to implement the specifications off-the-shelf for whatever language you fancy. My job is to clarify the 'what' which I think I'm quite good at, but I'm getting too old to write tight production code to do the 'how'. This is where some hard-core programmers are needed to get some code into the hands of application developers so we can iron out useability wrinkles. I have written a prototype and harness (in Delphi/Pacsal) which I'm using to fully investigate the library API - But it only happens in fits and starts so some encouragement would be most welcome. Join in Contact Peter Fox to get source, windows executable or suggest something

Questions

Real world example

Do your existing date methods allow for and distinguish between Invalid and Not known? Could your existing date methods handle the example form shown above? Are you going to retire after 2037? Can your date system handle the items in the Valid d/a/ys box above? What is 28 Feb 2009 plus one month? (Answer 31 Mar 2009)

Question How long has your arm been in plaster? Data Start : 3 May 2009. End : Still on :( Method Subtract Start from End Problem 1 Still on isn't a date in most schemes and has no numerical value. Solution Not yet is recognised by d/a/y. Problem 2 How can "Not yet" be used arithmetically? Solution By convention substitute 'Today' Result Sensible 'no-fiddle' ability to deal with real-world situations. This shows the usefulness of the ideas and also how additional logic or conventions are required in the richer d/a/y world.

A little bit of background

More details

I've been using a version of this for over a decade. I needed something that would sort, consume a small database footprint, and be able to deal with vague, unknown and 'before we started counting' and 'some unknown time in the future'. It is something that was easy to write, and gives so much flexibility. One joy is being able to give the user the opportunity to type in T for 'today', B for 'Beginning of time', E for 'End of time', and U for 'Unknown'. A database of authors can now happily accept real-world values for their dates of birth, death (many are still alive) and dates of publication. The UNIX timestamp problem is a time-bomb. If you want timestamp features such as logging then an overflow/wraparound in 2038 isn't too much of a problem but if the applications you use have it embedded then you could end up in trouble very soon. Although I'm clear this is not about textual date representation (there's already a standard for that), internationalisation is an issue that needs to be dealt with if any formatting and interaction is to be applied. For example error messages and allowed abbreviations extend 'normal' date internationalisations. That's why there's an add-on appendix system to configure input and output details. In times past I could have written a reference version in say Java but the advance of years means that I'm not as deft as I used to be and would rather leave that task to someone else. Do have a look at the overview, and if you have thoughts or would like to contribute then get in touch. Peter Fox June 2009

Documentation pdf Introduction and specification

This project needs volunteers or money to finish it off. Please contact day©vulpeculox.net

©