OK.

I should have provided some background information...

We've designed the new component so minimum effort is required from the user. That is, "The component shall allow users to enter dates with the least keystrokes possible".

As such, it is no longer a 'free form' input field. Instead, it is a strict-structure field with the format (dd/mm/yy).

Please watch this 1 minute video to get a sense of how it works. Notice the keystrokes shown at the bottom and how the component auto-advance you between partials.

To complement the video:

• Any keystroke you type feeds either the day, month, or year partials - as highlighted by the blue background.
• The component will auto advance you to the next partial whenever it makes sense to do so. For example, if you type '5' whilst on the day field, you'll be automatically advanced to the month partial.
• You can also move to the next partial using the right arrow keys or the delimiter, which is '/'.
• There's more, but the above gives you a general idea.

Colin. Given your reply, I've added '.' as something that will advance you to the next partial as well (same as arrow right or '.').

Carole. I hope that clarify things - you have no way of entering a 4-digit year.

Let me know your thoughts.

An update: we are soon to start testing on the new date field component.

There's just one thing I'd like to confirm with you stakeholders:

The research we did revealed that Clear Books users:

• Hardly ever enter dates more than a year in advance.
• Do need to enter birthdays (for employees).

As such we've designed the field (when entering dates) to have the format:

dd/mm/yy (not dd/mm/yyyy)

Meaning there are only 2 digits for the year (to save having to enter the 20XX). The cut-off year we've chosen is 10 years from the current year.

So for 2014, this means entering 24 would mean 2024, but 25 would mean 1925.

You won't be able to enter years below 1925, or above 2024.

We can obviously change this.

I just want to run this by users - can anyone think this can become an issue?

keep the pressure on for this one - nearly every other package is ahead of ClearBooks on this

Any updates on when this might go live?

Hi Rebecca,

It will be applied globally. Two weeks or so is the timeline.

Hi Carole.

Where would you like to see this happening? Because with the new date field (currently being at its final implementation stages) such text entry will result in such date.

looks awesome !

worth waiting for.

This is now live, on an opt-in basis.

Please read the announcement.

Sounds great, hoping it does come through as anticipated

Hopefully this will go live later this week - we're just fixing a few bugs we have found last week.

See weekly updates.

I did not want to push my luck so was quite happy to ask for what Carole (or even Carloe!) wanted ie ddmmyy to be recognised. However, you appear to have taken that beyond and gone to another level !

What you have done sounds quite complicated, but you are trying to achieve much more, so I am delighted with this, if my understanding is correct.

If there is room for change, can I suggest that the date defaults to current year unless typed differently. that would mean that I could enter, say, 5th May 2014 in two key strokes ie 5,5 which would be amazing !

Well done and let's get this released as soon as possible

Hi Roey, I wonder why you default to 19XX? The first time I saw that I thought it was a programming error. I don't know any system that doesn't default to 20XX. So far as entering a date all I'm looking for is to be able to enter ddmmyy and have it translated into 16/10/2014. Thanks for asking. Carole

I'd like to be able to enter any of the following and for the system to work it out (if no year is specified then current year would be assumed):

• ddmmyyyy
• ddmmyy
• dd/mm/yyyy
• dd/mm/yy
• d/m/yyyy
• d/m/yy
• dd.mm.yyyy
• dd.mm.yy
• d.m.yyyy
• d.m.yy
• ddmm
• dd.mm
• d.m
• dd/mm
• d/m

If a yyyy is used then use that year otherwise for yy the rules you suggest would work well.

The suggestion to cut the input down from dd/mm/yyyy to dd/mm/yy helps but does not go anywhere near far enough.

I'll be picking this one up next week - but I have no idea how much work is left, so no estimates at the moment.

is this live yet ?

4 months ago, the expected time to implement was one to two weeks

The developers are at the last stages of implementing it. We'll run tests next week, as it is a global change testing will take longer, but I reckon week after next is reasonable.

This is great news if/when it happens. How will you make users aware that the change has been implemented ?

Hi Roey, thats good news. Well basically everywhere! I think I was selecting dates for reports when I did this note. Trial Balance, P&L, Balance Sheet, Aged Debtors, Aged Creditors etc. Thanks