That's a long title, but it's the most simple way I could come up with in one sentence to explain the issue. Here's what happens, why I ran into it, how to reproduce it, and a work-around.

Background

I am responsible for a web application in Domino, in which I use a non-Domino "Date - Picker" control. The result of that control is a text string representing the date, which I need to turn into an actual date-time value at save time. Complicating this, is that different standards exist for representing dates. In the U.S. we use "MM/DD/YYYY" while in much of the rest of the world they use "DD/MM/YYYY". As a result, any date in which the day of the month is 12 or less, can be ambiguous. For example, 11/05/2015 could be the 11th of May, or it could be the 5th of November. Domino attempts to figure out which you're using based on your browser's locale settings -- or, if you've got a saved preference cookie, it will use the settings there.

In order to disambiguate the string before converting it with the @TextToTime() function, I decided to replace the numeric month with the actual month spelled out. Since my date picker always results in the date being MM/DD/YYYY, I wrote a bit of formula language code that computes "03/05/2015" into "March 05 2015". This could then be fed to the @TextToTime and there should be nothing ambiguous about it.

The Bug Reports

I started getting bug reports from users in other countries that were just crazy. In specific, a user reported that after using the date-picker to select "03/05/2015", when he saved the document it was being saved with the value "February 2nd, 2015". That would appear to make no sense at all. I used a remote shared screen to watch him do the selection, and he wasn't doing anything weird. Just picking the date and saving. I checked his browser version and it was the same as mine. I tried with my browser and it worked correctly. Every single time he did it, he got the wrong date. Every time I did it, I got the correct date.

Figuring out the cause

Until I could duplicate the problem, I kept having to make the user do the edits to test each small change. Since the user speaks Spanish and lives in Colombia, that was tricky. Finally, I realized it was a browser locale issue. I was able to force Domino to treat me as if I were a Spanish speaking user from Columbia, and then the problem happened to me as well. It seems that when my browser preference was for a date format of "dd/mm/yyyy" Domino would take the string "March 05 2015" -- ignore the word "March" and start with the numbers. It used the 05 as the day, saw the 2 next and decided that meant february, and the 15 made it 2015. So to Domino, "March 05 2015" was actually in February. --- But only if my browser setting was for "dd/mm/yyyy" and not "mm/dd/yyyy".

My Workaround

By changing the computed string from "March 05 2015" to "05 March 2015" the parsing works correctly for both date formats.

To reproduce the problem

1. Unless you plan to actually reconfigure your whole workstation as if you live in Colombia, make sure to turn on the Domino HTTP session cookie setting "Store Web user preferences in cookies".

2. Create a "Page" in a test database.

3. Create a computed field with the following formula: @ToTime("March 05 2015");

4. Create a computed field with the following formula: @ToTime("05 March 2015");

5. Label them so you can tell which is which when you browse to them.

6. Open the page in a browser: (e.g. //myserver.com/mytestdatabase.nsf/mytestpage ) to see that they are the same if you're in the US (probably not the same value if you are outside the US).

7. To force the server to treat your browser differently use the URL command to change your preference cookie. (e.g. ttp://myserver.com/mytestdatabase.nsf?OpenPreferences )

8. Select the "REGIONAL" settings on the left.

9. Select "Customize" and set your locale to "Spanish (Colombia)" then click "Load default preferences for this locale", and then save.



10. Go back to your test page and notice the broken results.
* Remember, in this picture, the DAY is first, then the MONTH because that's how the browser is set.
so this data shows March 5th on top, and February 5th on the bottom.


11. Go back to the preferences page and set your locale to "English (United States)" and again click "Load default preferences for this locale" and save.



12. Go back to your test page and notice the results are the same for both fields.



Let me know how it goes.