Idea for Date field (+ or - for default)

Today when entering a date, Panorama conveniently helps by picking the closest date to today, going forward or backwards + or - 6 months when the user has entered only the month and day.

I’d like to suggest that we have a default of + or - to indicate that we only want to have a forward date or a previous date as the default.

ie. If I have a column for a receptionist to enter a new appointment for a patient, they could enter a date 9 or 10 months into the future with just the month and day and always have it smart enough to know that the future was meant. Similar benefit when a historical date field was being entered.

Today, sometimes the ‘shortcut’ is used only to find that the 6 month window was overshot and the date has to be corrected wasting time and instilling non use of the shortcut.

1 Like

This might also be useful for 2 digit years. In a date of birth field, it would be helpful if it knew that xx/xx/50 was 1950 and not 2050.

Personally, I think I’d just as soon enter the additional digits rather than use the + key, which requires the Shift key.

I’ve sometimes thought about changing the “window” to be more like 10 months in the past 2 in the future. For my usage, that would be more useful, as I rarely enter dates in the future but often do so in the past (usually for bookkeeping). But I can see it’s a good thing I haven’t acted on that idea, since some people are more concerned about future dates, like future appointments. I kind of suspected that which is why I haven’t changed it.

For the years, it probably would make sense to skew the “window” to the past. I doubt if dates more than a couple years in the future are entered very often. It’s probably much more likely that xx/xx/40 is 1940 and not 2040.

I wonder how many people even know about or use this date shortcut feature?

  • I use date shortcuts all the time.
  • I use date shortcuts occasionally.
  • I rarely/never use date shortcuts.
  • I don’t know what date shortcuts are.

0 voters

My thoughts were that the + or - was part of the setup for that field when designing the database as ‘that field’ will always be in the future or in the past. (An appointments field would be in the future, a birthdate field would be in the past.) I am not requesting on an entry by entry basis.

Robert Ameeti

I didn’t understand that from your suggestion, I guess I missed where you suggested + or - as “a default”.

However, I was actually going to reply that this idea that would be nice if it was enabled on a field by field basis, so we are on the same wavelength. Unfortunately, the code that parses dates isn’t really connected to a field. For example, you could have a date( function in a formula, and there isn’t a field anywhere in sight.

 date("3/30")

So this would be non-trivial to implement.

I think it is a good idea, though, so I’ve put it into Bitbucket as a proposal for future consideration.

BTW, I think this should be a separate field property, not linked with the default value. Using the default value would have the advantage of not requiring any user interface changes, which is probably why you suggested it. But I think users would find this an unexpected overload of the default feature, and even if the date is designated as future or past you might still want it to default to today or ditto.

I do appreciate the fact that the programming will be more than a small change but I must comment in reply to your thought that your not sure how often this feature is even used. As it is now, it is of very limited value. But…

In a medical office they are making appointments, entering data from tests taken, entering birthdates, entering insurance dates, etc. Every occurrence is a known forward or backward date. It is difficult to explain, and of limited use, to share that they can leave off the year when it is only valuable for the near 6 month time frame. The value of this change would make it 100% useful if the user could count on it always being correct.

I’m always disappointed that this neat feature is most often not as handy as it could be.

Robert Ameeti

While I see your point and the value of such a default setting, you can certainly add it to your databases now. It takes the addition of a procedure triggered by data entry into specified date fields to recognize that an entered date is a past date and shift the year forward.

I totally get that I or anyone else can accomplish the end result today. We can do anything we want with Panorama. That is why we use it. :slight_smile: My point was geared towards Jim’s comment as to ‘how many people even know about or use it’. My thoughts are that with the current implementation, few use it, and few can easily use it as it can be frustrating and limited. Only with the suggested change might many find it useful in their desire for everything to ‘just work’.

Most people don’t want to work hard, nor do they want to think.

Robert Ameeti

I use “Date of Birth” = ?(“Date of Birth” > today(),monthmath(“Date of Birth”,-1200),“Date of Birth”). The database I use it on has one person who is over 100 years old, but I entered his birthday a long time ago.

Yep, another method to handle it for the user.

The problem with these kinds of workarounds is that they do not allow for the user to enter the entry which does not follow the rules for whatever reason. Using a formula like the one your prescribed disallows the user from having full control. Life always has exceptions and we need to allow for them as well. it is the default that needs to be adjusted. And someday it just might be done. Today is not looking good. :wink: