Date field limitations

[Rob Keeney]

A few questions about the Date field (sorry if these have been addressed before):

1. I can enter dates prior or 1900 on the desktop version but not on the Android app; why not?
2. Dates displayed as 'status' show up only in one format: mm/dd/yy. Is there an option to change the display format to perhaps mm/dd/yyyy (or anything else, for that matter)? If so, where are those options made available to edit?
3. Any suggestions for workaround if only a partial date is known (year only)? It would be beneficial to enter years and/or months even if days are unknown (useful in my case for birth/death dates of ancestors).

Regards,

Rob..........

[Rob Keeney]

I answered my own questions (at least numbers 2 and 3) using JavaScript. In case anyone else is interested, this is how I did it:

1. My date field for births is 'DoB' (regular date filed when the exact date is known).
2. I created another plain text field for partial dates, 'YoB', in which I can enter whatever information I have, such as 'January, 1927'.
3. The JavaScript code that works for me tests whether the date field has a value, and if not displays the plain text field (both appended by 'b ' to indicate born on...

if (!!field('DoB'))

    var DisplayDate = 'b '+moment(field('DoB')).format('ll')

else

    if (!!field('YoB'))

        var DisplayDate = 'b '+field('YoB')

    else

        var DisplayDate = 'unknown DoB'

DisplayDate

[Bill Crews]

Thanks for posting. It should be mentioned that, for this to work, one must check the box within the JavaScript field definition under JavaScript Libraries for the moment.min.js library.

As for your original question #1, people who have used Unix or Linux are aware of the "standard Unix date format". It was invented when computers used "word" storage rather than byte storage, with two or four bytes making up a word. Computers were fast working with words, so when the Unix founders defined a format for dates, they saw that they could fit a number of seconds in a 4-byte word that would span 136 years. So, they based their dates on seconds since the beginning of January 1, 1900. It would work until 2036 -- far into the future from 1969. A 64-bit word would've worked much better, but on computers of that day, it would have slowed things down tremendously.

Nowadays, there are faster computers and other standards for storage of dates, but that old one lives on and is the standard for Memento on Android -- and apparently not on your desktop platform. I hope Memento is free of this constraint at some point. It is archaic.

[Rob Keeney]

I found that the moment.min.js library loaded automagically for me. I thought I would have to manually add it, but I didn't need to (at least so far).

Thanks for the clarification on the dates. Isn't it odd that the display date is fine once I add it using Windows desktop, but can't use the Android app to add it?

Rob..........

[Bill Crews]

I don't understand this at all. Please tell us what happens in desktop and then what happens or doesn't happen in mobile. Thanks in advance.

[Rob Keeney]

Suppose I want to enter a date prior to 1900. If I try doing that using the Android app, I can't enter the date directly as in simply typing 8/21/1848. I have to use the scrolling years and months (which is very annoying and overly time consuming) and the earliest year in the scroll is 1900. However, if I use the Windows desktop app, I can enter the date directly (no scrolling required) and it accepts a pre-1900 date (don't know how far back since I haven't tried anything before 1800). Once entered, if I go back into the Android app, the date shows up correctly.

So, based on this, I assume there's not a problem having a pre-1900 date as a proper data record, I just can't use the Android app to enter nor modify it. Hope that makes sense.

Rob..........

[Bill Crews]

Ah! Sorry. You were referring specifically to the pre-1900 issue. I got it now.

But now I have another question. Are you suggesting that you can enter a date in 1848 on the desktop and on the mobile edition, you can see it displayed correctly? If so, then can you edit it or use it in a calculation? I seriously doubt the latter, and I doubt the former, as well. As far as I know, we're just stuck with post-1900 in the mobile edition.

Of course, with a little JavaScript here and there, you could construct old and future dates and display them in the mobile edition. Would you like that? It wouldn't be nice and generalized, but you could make it how you want it. Dates would have to be displayed in JavaScript fields, not Date fields, and all arithmetic with them would have to be in JavaScript, as well.

[Eugene Kartoyev]

Hmm... it's true Memento doesn't allow years outside the 1900-2100 years range.

Android's java machine (called DVM) uses long type of variables for dates, so one could track his ancestors up to Sun, 2 Dec BC 292269055, 16:47:04 +0000

It was the moment when our forefathers first set their flippers on the dry land crawling out of the Ocean.

There was a question about the datepicker limit in StackOverflow.

Apparently the specified range is default. But it may be changed if the developer sets a range in the program's code for the datepicker.

http://stackoverflow.com/questions/24335691/android-date-picker-pre-1900

So, one might as well raise an issue in the uservoice. It can be resolved by a one-line code.

[Rob Keeney]

Bill, I have used the dates in JS calculations (as indicated in an earlier post). The dates show up as expected, so I assume they are stored correctly.

Rob..........

[Bill Crews]

OK, I'll just guess what platform you're talking about -- desktop Windows?

My question was: If after that you view the entries on Android, what do you see in the Date fields?

[Rob Keeney]

Yes, desktop Windows. When viewing on Android (after entering or editing the date on Windows desktop), I see 8/21/48 (for Aug 21, 1848). As I mentioned, if I use that date in a JS calculation, I can have it display as 8/21/1848 using the moment.min.js library.

Just curious, do you see something different?

Rob...........

[Bill Crews]

You see, the Android Memento app has its own code, of course, and it also uses a SQLite database engine. It could be that the engine generates the displayed value, though I would have thought the Memento front end would do that. I'd like to identify which part of the app fails to display 1848, and which part fails to enter/update 1848. So, I need to do some testing.

Thanks for your help.