date, time and numbers

• Safe handling of date and time
• the user should only see his local date and time
• the device setting is evaluated, the user must make sure that the device is adjusted accordingly when changing the time zone - and that the time is correct, so the clock is correct and is synchronized with the Internet
• program-internal UTC is expected and used
• storage is deliberately redundant: 
• the local time, as displayed to the user on the client
• the local time from the client as ISO-Date
• the server-time as ISO-Date
• JavaScript toLocaleDateString is used with an additional function using regex to ensure that days and months get two digits
• that was the theory until the tests on safari and iOS were done
• Safari works a little bit different
• also the new date() function does not accept an ISO day or an ISO date, so the standard with year, month, day as integers, separated with comma as paramters had to be applied
• JavaScript toTimeString is used with truncation
• User inputs are entered and checked using jQuery Mobile Datepicker  (see the example and regard the usage of the libraries, specially the sequence)
• internal calculations are based on the native Date (UTC)
• http://stackoverflow.com/questions/9023818/correct-way-to-change-specific-dates-cell-background-color-on-datepicker - this is used to mark days for which diary data is already entered in the datepicker
• http://stackoverflow.com/questions/38527021/styling-datepicker-highlight-specific-dates is used to update calendar days when they are clicked for adding diary entries, but: td is a little bit too general and it is better to update the JSON-structure with active dates, because that assures an actual display on the next navigation to the calendar page
• $("#mydatepicker").datepicker("destroy"); - is necessary to clear the highlights in datepicker, e.g. when a new user logs in

The challenge to work with dates is not yet quite finished. Ninas Travel App is used for work and travel in Australia, that means:

• a server in USA has the local time from an US-timezone (Red Hat Cloud)
• in Australia there are 4 timezones that will be travelled to
• in Germany there is another timezone
• and in Great Britain is the Geenich Meantime (GMT, UTC Base)

Question is: what do I in Germany want to see, when Nina enters data into the diary:

• the Australian local time - because Nina is living in that timezone
• the German local time - because I want my own entries with this timezone
• the server-time of USA - because this could be a compromise between Germany and Australia
• or the GMT - but no one is in England
• summertime and wintertime are not an issue so far, this information is implicit and not necessary in a diary context (but in technical and business applications that's different)

What would I expect in a timeline, where all diary entries of Nina and me are sorted according to "entry time". My solution with the redundant data:

• sorting is done based on the server-date UTC
• Ninas entries are shown with her local time and the hint to the timezone (West Australia at this time)
• My entries are shown with my local time and hint to my timezone (MEZ)
• if a filter on date has to be done
• the users enters his date as local date
• the ISO-Datestring is calculated
• filter is done with the ISO-Datestring
• the result is not always as expected, because "you think in your local timezone", when you say "today" or "yesterday" and that doesn't necessarily match with people in another timezone - so filtering on date is restricted in the diary system, you can scroll and choose dates with the datepicker, that's it

As a consequence I think I have to program a "local ISO Date-String", that correspondents to the user-expectation and it can be processed easily.

At the moment datepicker doesn't show in iOS browsers. Tests are done.
http://stackoverflow.com/questions/2682259/jquery-ui-datepicker-not-displaying - and Safari on Windows 10 is working well

• Safe handling of numbers
• JavaScript is quite comfortable in the automatic conversion of numbers
• but that does NOT apply when accessing the database, then the selection criteria must exactly match the format of the data in the database
• The formatting of numbers is well supported with jQuery plugins, this as an entry https://github.com/jquery/globalize/tree/master/doc/api/number for formatting and parsing and for "as-you-type automatic formatting of numbers in input elements" then https://github.com/customd/jquery-number
•