Manual Date Entry

[DaFranker]

I'm not sure whether I'm just blind, or if my search skills have severely rusted down, but anyways. I've found lots (and lots and LOTS) of threads and comments that request / suggest / demand / threaten-for / ultimatum / beg / cajole about adding different calendar options.

I haven't found a single mention of my biggest gripe with the current timeline and date entries: the absolutely inconvenient clicks-only entry of every single date. I want to be able to just type "23/07/1924" (or well, actually, "07/23/1924" because the datetime control RW uses apparently runs on the exotic US-only mm/dd/yyyy format regardless of the user's OS format settings, and despite the fact that the US is literally one of only two countries that favor this format and there are only eight countries that use it at all for some applications).

Apparently, I can't. To enter the date above, the fastest way I had just moments ago was:

1. Click the control arrow to open the popup
2. Click "January, 1999"
3. Click "1999"
4. Click "1991-2000"
5. Click "1921-1930"
6. Click "1924"
7. Click "July"
8. Click "23"

...Seriously?

I understand that RW mostly uses pre-baked controls from DevExpress, but even then, I'd think they would have other DateTime controls that can handle manual input (typing the numbers directly in the control without popping up the selector tool).

Is this something I'm just completely missing that is already doable? Or is the procedure above really the fastest possible way we currently have to enter dates?

If it is, I'd love if we could at least get those controls quick-patched with another control type that supports manual entry in the meantime, as having to wait until the long-prophecied "Calendar" feature update to simply be able to conveniently enter a bunch of dates for my game system that actually does use the Gregorian Calendar is... well, I won't go so far as to say "depressing", but I'll definitely throw around "ironic".

[daplunk]

OMG this.. so much this.

+1000

[Silveras]

So... what's going on here is this:

RealmWorks has a 100% custom implementation of calendars. LoneWolf implemented the real-world Gregorian calendar as the basic calendar in this 100% custom system.

The Good: This system is designed to support any variation of a calendar, for fantasy, for far-future science fiction, for the present-day real world.

The Bad: LoneWolf is stuck "re-creating the wheel" to create their own controls for date/time display and input.

There have been threads about input using simple text. I know at least some are in the Beta tester forums, but I know there are more in the general forums as well.

So the issue is this: To support entry of virtually any date in any kind of crazy calendar... it is not capable of parsing text to do so.

[Chemlak]

I think I can safely say that LWD definitely want manual date entry (I know I do, too!), but for the abilities of custom calendars, it's hard. Really, really hard.

So, yes, want it. Not expecting it any time soon.

[DaFranker]

Originally Posted by Silveras

(...)
So the issue is this: To support entry of virtually any date in any kind of crazy calendar... it is not capable of parsing text to do so.

Originally Posted by Chemlak

I think I can safely say that LWD definitely want manual date entry (I know I do, too!), but for the abilities of custom calendars, it's hard. Really, really hard.

So, yes, want it. Not expecting it any time soon.

I'm sure you guys have a good reason for thinking that the text-entry part of a custom fantasy everything-goes calendar is separately really hard in a different kind of way, but...

It's not.

Exhibit A.

Yes, that's a completely custom javascript app here that Wizards made for the FR Calendar. However, I'd like to point out here that one of the parts of it that was possibly the easiest to make for them, if you have a quick look through the code, was being able to select a month and a year with your keyboard. You could very easily replace the dropdown for the month with a text-entry field that only accepts a number from 1 to 12 with very minimal effort (a couple hours at most for a programmer unfamiliar with javascript - about 30 minutes for someone who's both expert at javascript and already familiar with this particular app). Of course, doing that and sharing it would be a breach of WOTC's copyright.

The only assumptions that need to be made in order to be able to accept text-input date entry as numbers are:

• The calendar is made of subdivisions of time, each lower subdivision being contained within the higher subdivision
• Subdivisions are ordered and do not change order regularly
• If the subdivision ordering changes (for example, every three years June-July-August become the 2nd-3rd-4th month of the year and the rest of the months follow), this already requires scripting logic in which case a scripted number-to-name interface method needs to exist either way, even moreso for any kind of visual datepicker than for manual datepicking.
• There are rules that allow us to determine which possible elements of a subdivision are "valid" elements within a particular element of the higher subdivision, e.g. "29" is not a valid "Day" element for the month "02"/"February" when the "Year" element is [etc., you know how that works]

(there are a few other implicit assumptions that I didn't think of, most likely...)

You'll note that these are also requirements in order to have any kind of visual picker for fantasy calendars.

Weekdays are a particular thorn, because they are not part of the calendar yet are often portrayed as such. Let me clarify that: Weekdays are actually just a parallel subdivision of the year that is under "Weeks", and "Weeks" begins on the first day of the year not occupied by the leftover of the last week of the previous year and ends on the last full week for which the first day was within the same year. Then, within each of these weeks of seven days, each of the seven subdivisions are named.

Notice here that they're just a parallel process and are never involved in the actual selection of a date. I will never enter "Thursday, Week 42, 1964", though I could find the date where Week 1 begins in 1964 and then find the Thursday of the 42nd week of 1964.

So, in essence, Weekdays are a special case of parallel calendars, and much more fancy types of weeks should be possible if LW are doing this fancy custom Calendar system right, but my point is that weekdays and parallel calendars are also irrelevant for selecting a date in the main calendar. In my main calendar, I'm entering "15, 10 (October), 1964". And then, the mathematical logic in the background calculates for me that this is Week 42 and that it's a Thursday.

A further complicating factor here might be that the valid dates in one "calendar" the way I've defined this here might depend on the cycles or subdivisions of another parallel "calendar" the way I've defined it here.

For example, let's say I have a fantasy world with three moons and no relation whatsoever to Krynn, and whenever these three moons all have a full moon within the same month, that's it, that's the last month of the year, no matter what (even if it occurred within the first month of, say, 1348, then 1348 is one month long and then 1349 begins immediately afterwards, getting the same month twice in a row!). This calendar isn't supposed to make sense, it's supposed to work like George McKing of Alasteriel decided it would work.

Right, sounds complicated?

I punch in 33-02-1348 in my custom date entry field. As soon as I change focus away from this field to another control, it changes itself to 35-01-1348 because that's the nearest valid date earlier than what I entered, as "02" is not a valid subdivision-2 ("month") for the subdivision-1("year") numbered "1348" (and "1348" could potentially be named "Year of the Hastened Goddess" or whatever, just like the month "01" might be named "Aelmont" or "Snowfun" or "Famine" or whatever...).

Where's the difficulty in that? In order to determine that 02 wasn't a valid month for 1348, I had to use the very exact same methods in my program that are also absolutely necessary if I want to be able to have the list of valid months for 1348 displayed in a popup datepicker control. The very exact same.

If LW are having lots of trouble with the custom calendars, I'm fairly certain mapping the subdivisions to ordered numbers is already something they have to do, and I'm fairly certain that looking up an element using the index (number) is also something they already have to implement, and I'm also fairly certain that they already have to either check for each number whether that number is valid for the higher-level subdivision (in order to know which numbers to display in the picker popup) or have a function that needs the higher-level subdivision (e.g. year number) and provides a list of valid subdivisions (e.g. valid months), in which case you can compare that list of valid ones to the reference numerical mapping, check if the number entered is part of the returned valid elements, and get the same answer either way.

Whew, so I've unintentionally gone on quite long about this, but let's just wrap that up by saying I'm not seeing the difficulty of having manual date entry, especially of letting us have Gregorian-calendar-only-manual-date-entry in the meantime as a temporary relief until the Calendar system does release, for which manual date entry will also be trivial compared to the numerous other difficulties they face there (remember how I mentioned above ending the year at the end of the month where all three moons are full moon? Yeah, let's see anyone find a good user-intuitive way of being able to freely define anything like that without having to go deep into complex scripting...)

[AEIOU]

My understanding from the many, many calendar conversations over the years is that it's not a matter of it being too difficult. Or that they lack ideas on how to implement. It's simply a matter of carving out time to code it. Time is the enemy.

[Teresa]

If it were that simple, I'm sure they would have already done it. Like Chemlak said, "LWD definitely want manual date entry".

I don't want to start a war, but I've read enough posts by Rob asking us not to make assumptions when we don't know the real details. I trust they' ll do a great work - I find it much worse dealing with weird American date conventions.

So: here goes a vote for text-input of dates, which will probably be tied up with the calendar they are working on, whereas we are using just a temporary fix.

[Silveras]

Yeah, it is a matter of resources. LWD is a small company. Right now, they're focused on the Content Market, which is sort of necessary in order to keep RealmWorks alive as a product so they can then turn to other issues.

[kbs666]

The problem is that the above assumes every calendar will have days, weeks, months and years. Nothing could be further from the truth.

Consider for instance the Star Trek stardate system which, definitely, has none of those.

Or consider the world of Westeros. Seasons last for "years" and end unpredictably. I've never been quite sure, been a while since I read any of the novels, how they determine a year but obviously the planet doesn't orbit a star like Earth orbits the Sun so a calendar system on such a world would not be solar based.

Then consider a setting like Pellucidar. In a hollow world where there are no heavenly bodies a calendar would need to be entirely different.

[MaxSupernova]

I always thought they just de-prioritized the calendar input until they implement customer calendars as a feature.

So, yes it's inconvenient, but when custom calendars get implemented it will be substantially different so time spent fixing it now is wasted.

That's a complete guess, but it's been my assumption for a while now.