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 (https://en.wikipedia.org/wiki/Date_format_by_country#Map) 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:


Click the control arrow to open the popup
Click "January, 1999"
Click "1999"
Click "1991-2000"
Click "1921-1930"
Click "1924"
Click "July"
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]

(...)
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.

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 (https://www.wizards.com/dnd/fc/index.htm#).

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.

[DaFranker]

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.

No. This is not an assumption in what I said. I was very careful to primarily use the words "subdivision" everywhere and use Years/Months/Weeks/Days as merely examples of these subdivisions.

It's just as easy to make a textbox that accepts 41153.7 as to make a textbox that accepts 23/07/1924 or one that accepts 56/02/1245.

For the Westeros example you bring up, for things like seasons that may or may not be longer than one year or where there might be multiple of them in a single year at times, this is the same as the "Weeks" special case of "parallel" calendars I described, because in such a situation you wouldn't use the season as part of the main numeric, ordered dating. So the season simply wouldn't be part of the number you type in.

My general point is: Regardless of the (definitely humongous and daunting! absolutely way more complex than I could represent in my last post!) complexities involved in the systems required for supporting multiple calendars, entering a number to represent a particular date within any given calendar is not what is difficult. I can whip up a text-based control that accepts arbitrary date formats and tells you which date, week, season or stardate it is within a couple of hours at most. If you want it to be able to accept multiple possible calendar types though, that's going to take me weeks if not months, full-time. A decent example of something like this already done is this jQuery multi-calendar date picker (http://keith-wood.name/calendarspicker.html), but as you can see if you dig around they had to manually code every single calendar option, and building the framework to support all of that obviously took years of part-time community effort, as you can tell by the version history.

That's not even what I'm saying though. What I'm saying is that could we pretty please have text entry of dates for just the gregorian calendar in the meantime pretty please? That takes me literally 10 minutes to do in AutoIt using built-in controls code (http://pastebin.com/TgjmYmf5), and I can't imagine it would take weeks to swap the control in RealmWorks for another already-existing DevExpress control.

I can definitely understand if this is not something they're willing to do in order to maintain the codebase stability moving forward as they integrate more and more different elements of the datetime controls and calendar system into the rest of the application. I can also understand that adding this functionality into there is not a priority and the hours it would take to do this are better spent elsewhere for the moment. That's all good.

[kbs666]

No. This is not an assumption in what I said. I was very careful to primarily use the words "subdivision" everywhere and use Years/Months/Weeks/Days as merely examples of these subdivisions.

It's just as easy to make a textbox that accepts 41153.7 as to make a textbox that accepts 23/07/1924 or one that accepts 56/02/1245.

For the Westeros example you bring up, for things like seasons that may or may not be longer than one year or where there might be multiple of them in a single year at times, this is the same as the "Weeks" special case of "parallel" calendars I described, because in such a situation you wouldn't use the season as part of the main numeric, ordered dating. So the season simply wouldn't be part of the number you type in.

Hold on there. Software doesn't work that way.

Entering a text string in a box is meaningless unless you also have some way to convert that into something meaningful about the calendar/time data
you want to convert it to. A date entry of 23/07/1924 gets converted into July 23rd 1924 only if the software understands "mm/dd/yyyy" strings as dates and has the correct conversion routines.

Further you have no idea what would or would not matter to tracking dates and throwing away information is never a good idea. A Westeros calendar could number years of the current season just as some cultures here on Earth numbered years based on the rule of the present monarch.

[DaFranker]

Hold on there. Software doesn't work that way.

Entering a text string in a box is meaningless unless you also have some way to convert that into something meaningful about the calendar/time data
you want to convert it to. A date entry of 23/07/1924 gets converted into July 23rd 1924 only if the software understands "mm/dd/yyyy" strings as dates and has the correct conversion routines.

Further you have no idea what would or would not matter to tracking dates and throwing away information is never a good idea. A Westeros calendar could number years of the current season just as some cultures here on Earth numbered years based on the rule of the present monarch.

Thank you, I think we both came from different assumptions and this was a pretty big step towards bridging that gap.

Yes, it's pretty much part of my point that one way or another, for any custom calendar the user creates there needs to be a way the user can... generate? define via script?... some sort of input-to-date representation, both for a text input or for a date-picker input. It's likewise meaningless to give the user a UI to select numbers on a grid if those can't translate to the internal representation of a date, and having only an internal description of the calendar without any interface defined for the user to input one is barely any different for the end-user.

The idea of having a date representation include an unstable variable that might either contain other subdivision or be contained by those same subdivisions feels pretty alien to me (i.e. what you describe for using unstable seasons as part of the date representation), but I'll grant it's not outside the realm of what people might attempt. I just can't imagine any reasonable way where any input format OR datepicker might represent this coherently without some very heavy calendar-specific custom scripting.

[rob]

You're going to have to trust me when I say "It's frickin HARD". :)

Beyond the calendars above, you might consider looking at the Tolkein calendar. Or the Forgotten Realms calendar. Or the calendar for Warhammer 40,000, which will make any sane brain crawl into a corner and whimper at the thought of modeling it in a concrete manner. There are numerous other examples from gaming.

If all you want is a text value, which is what it sounds like, then you can just define your own label-based text snippet type on the categories you want. From there, you can enter the text for these dates, where you are wholly responsible for ensuring that each date is properly formatted to whatever conventions you care about. That might be all you really want and need here. :)

[kbs666]

Rob,

its been established in other posts that RW is written in C#. That means it is possible to expose a scripting interface, CSScript is the most common in .Net usage but there are others.

It may not be the only solution to calendars, or a lot of other things, but if you make such available soon the community will extend and expand RW in ways you and your team will never have time or resources to do on your own.

[DaFranker]

You're going to have to trust me when I say "It's frickin HARD". :)

Beyond the calendars above, you might consider looking at the Tolkein calendar. Or the Forgotten Realms calendar. Or the calendar for Warhammer 40,000, which will make any sane brain crawl into a corner and whimper at the thought of modeling it in a concrete manner. There are numerous other examples from gaming.

If all you want is a text value, which is what it sounds like, then you can just define your own label-based text snippet type on the categories you want. From there, you can enter the text for these dates, where you are wholly responsible for ensuring that each date is properly formatted to whatever conventions you care about. That might be all you really want and need here. :)

Thanks, that's sort of what I'm doing for now (and abusing prefixes within Time Period / Event List / Event topic hierarchies), but what I'd really love is to leverage the Timeline feature combined with snippet tags, so I can say bring up a timeline of all the corporate-related events from 2062 to 2064 (during/after Crash 2.0 in Shadowrun, a major metaplot event) or other fancy things like that.

I've tasted those features and now looking at my badly-sorted lists and hierarchies of events by prefix and having to hunt down a bunch of other places to find certain things feels like a significant step backward.

I'm entering dates as snippets where I can for things I know I'll use the Timeline + Tag searching, but that's 5 to 8 minutes for each such snippets (if you consider finding the info, entering the date and annotations, and then adding the snippet tags), so that makes the work/reward ratio less attractive.

Rob,

its been established in other posts that RW is written in C#. That means it is possible to expose a scripting interface, CSScript is the most common in .Net usage but there are others.

It may not be the only solution to calendars, or a lot of other things, but if you make such available soon the community will extend and expand RW in ways you and your team will never have time or resources to do on your own.

I'll definitely back/second that, though here I'm more than aware there's usually a lot of work involved in setting up the interfaces for what scripters should have access to and what they shouldn't, and this is made way more important by the Content Market and the protections that have to come with the proprietary content.

Done right it could be a significant enhancement on par with allowing HeroLab custom Data Files though, or even as important as MapTool/Mote scripting.

[Silveras]

I've tasted those features

Any chocolate? Vanilla's ok, too, but...

More seriously, one tip to remember is that RealmWorks "remembers" the last date entered and uses that as a default for the next. If you can work with your dates in clusters, that may make things a little easier.

[rob]

its been established in other posts that RW is written in C#. That means it is possible to expose a scripting interface, CSScript is the most common in .Net usage but there are others.

It may not be the only solution to calendars, or a lot of other things, but if you make such available soon the community will extend and expand RW in ways you and your team will never have time or resources to do on your own.

Given the vastness of everything RW can do, opening it up to scripting will create a HUGE amount of additional work. Scripting for RW, especially with its diversity of content, would be at LEAST as complicated as for Hero Lab. So we'd need to come up with the scripting language extensions for controlling all the aspects of RW, rework all the internals to support that scripting, expose a means for others to wire in their scripts, support detailed error checking an reporting to support scripting, test everything, document it all, yadda yadda yadda. Moreover, any scripting locks in how stuff works, so anything that still needs refinement (like calendars) isn't even a candidate for scripting until that happens, which basically invalidates your stated objective.

Your post above makes it all sound so simple and easy. You probably know better, but all the non-developers out there using RW won't. They can easily see your comment and make the assumption of "why don't they just do that?". So I'd be irresponsible if I didn't point out how your suggestion here completely glosses over all the complexities of actually making it happen and effectively misrepresents the work involved to anyone not in the know.