Andrew Pollack's Blog

Technology, Family, Entertainment, Politics, and Random Noise

There's a bug in how @TextToTime() and @ToTime() process date strings related to international standards and browser settings.

By Andrew Pollack on 02/26/2015 at 02:52 PM EST

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.


There are  - loading -  comments....

re: There's a bug in how @TextToTime() and @ToTime() process date strings related to international standards and browser settings.By Dwight Wilbanks on 02/27/2015 at 03:33 AM EST
This is a great start at finding an explanation, and does explain some of my
evidence.

I use a tool called fiddler to monitor web traffic to a server, I can see using
the local settings that a cookie is being set:

DomRegionalPrfM
:6:UTF-8:es-CO:0:/:%3A:0:a.m.:p.m.:1:%2C:1:%24:0:1:.:1
:6:UTF-8:es-CO:1:/:%3A:0:a.m.:p.m.:1:%2C:1:%24:0:1:.:1
:6:UTF-8:es-CO:2:/:%3A:0:a.m.:p.m.:1:%2C:1:%24:0:1:.:1

Using the composer portion, I can go in and edit the data being sent to the
server, using a setting of 1 for the date format I get these results on the
same page, using the cookie:

@TextToTime("1/20/2003")
2003/01/20
@Month(@TextToTime("1/20/2003"))
1
@TextToTime("1/2/2003")
2003/02/01
@Month(@TextToTime("1/2/2003"))
2


NO! NO! NO! It should throw an error!



I've got domlog enabled on a server with this issue, I can go back to my
original users submissions and see that they don't have that cookie set. (let
alone that they don't know its a domino server, nor do they know how to get to
?OpenPreferences)


I have a 9.01 server that does render those dates correctly. I could be that
IBM has fixed it, it could also be that there is some other server setting that
is different.
re: There's a bug in how @TextToTime() and @ToTime() process date strings related to international standards and browser settings.By Fredrik Norling on 02/27/2015 at 03:59 AM EST
Or you could change the date format to only accept the servers locale.
And decide for everybody how date should be written for this server.
re: There's a bug in how @TextToTime() and @ToTime() process date strings related to international standards and browser settings.By Dwight Wilbanks on 02/27/2015 at 09:57 AM EST
In my case, I was saving a computed field using a dblookup, The user never
actually entered a date. Upon creation of a document, it looks up information
from a document specified on the query string and saves it in a date field
along with some other text values.

Users that have date formats of YYYY-MM-DD, like French Canada fail using the
@TextToTime("5 March 2015") on servers version 8.51 and above. Servers 8.0 and
below process @TextToTime("5 March 2015") correctly using French Canada
Settings, I don't have access to a 8.5.0 server

My solution was to use a Web Query Save to overwrite whatever domino computed,
but, I now know that the only way to successfully do this is to take the text
value of the date from the dblookup, parse it into the format that I know it
uses (because I put it in the view) then use @date(). A long way around, but,
will work in every environment.

Also, I since my users are first timers using my server (and domain) they don't
have the cookie set and have never visited ?OpenPreferences. It's still a
mystery how domino is figuring out their preferences.
re: There's a bug in how @TextToTime() and @ToTime() process date strings related to international standards and browser settings.By Andrew Pollack on 02/27/2015 at 11:36 AM EST
The local preference cookie is only used if it exists, otherwise Domino gets
the information from the browser. Check out the full header, not just what is
in domlog. I believe you're looking for the locale variable.
re: There's a bug in how @TextToTime() and @ToTime() process date strings related to international standards and browser settings.By Dwight Wilbanks on 02/27/2015 at 12:57 PM EST
Got it! That was the missing piece. What domino is referring to as locale is
the Accept-Language http header. I was watching the actual http traffic, but,
didn't know that the Accept-Language was being used to force the date
processing.
When I switched the Accept-Language header from en-US to fr-CA
@Month(@TextToTime("5 March 2015")) r
re: There's a bug in how @TextToTime() and @ToTime() process date strings related to international standards and browser settings.By Dwight Wilbanks on 02/27/2015 at 12:57 PM EST
returns a value of 5
re: There's a bug in how @TextToTime() and @ToTime() process date strings related to international standards and browser settings.By Lars Berntrop-Bos on 02/27/2015 at 05:22 AM EST
in Germany they use dots as seprator i.e. dd.mm.yyy.
Yep international dates are a pain.
I ususally try to use ISO, i.e. yyyy-mm-dd. And if i have the choice avilable,
use a date type var instead of a string.


Other Recent Stories...

  1. 05/05/2016Is the growing social-sourced economy the modern back door into socialism?Is the growing social-sourced economy the modern back door into socialism? I read a really insightful post a couple of days ago that suggested the use of social network funding sites like “Go Fund Me” and “Kickstarter” have come about and gained popularity in part because the existing economy in no longer serving its purpose for anyone who isn’t already wealthy. Have the traditional ways to get new ventures funded become closed to all but a few who aren’t already connected to them and so onerous as to make ...... 
  2. 04/20/2016Want to be whitelisted? Here are some sensible rules for web site advertisingAn increasing number of websites are now detecting when users have ad-blocking enabled, and refuse to show content unless you "whitelist" their site (disable your ad-blocking for them). I think that is a fair decision on their part, it's how they pay for the site. However, if you want me (and many others) to white list your site, there are some rules you should follow. If you violate these rules, I won't whitelist your site, I'll just find content elsewhere. 1. The total space taken up by advertisements ...... 
  3. 12/30/2015Fantastic new series on Syfy called “The Expanse” – for people who love traditional science fiction[] “The Expanse” is a new science fiction series being broadcast onthe Syfy channelthis winter. It’s closely based on a series of books by author James S. A. Corey beginning with “Leviathan Wakes”. There are 5 books in the “Expanse” series so far. If you’re a fan of the novels you’ll appreciate how closely the books are followed.TIP: The first five episodes are already available on Syfy.com. If you’re having trouble getting into the characters and plot, use those to get up to speed.The worlds created for ...... 
  4. 10/20/2015My suggestion is to stay away from PayAnywhere(dot)com  
  5. 08/07/2015Here is one for you VMWARE gurus - particularly if you run ESXi without fancy drive arrays 
  6. 08/06/2015The Killer of Orphans (Orphan Documents) 
  7. 06/02/2015Homeopathic Marketing: Traveler on my Android is now calling itself VERSE. Allow me to translate that for the IBM Notes community... 
  8. 03/17/2015A review of British Airways Premium Economy Service – How to destroy customer goodwill all at once 
  9. 02/26/2015There's a bug in how @TextToTime() and @ToTime() process date strings related to international standards and browser settings. 
  10. 01/21/2015Delivering two new presentations at Developer Camp (EntwicklerCamp) 2015 in Germany 
Click here for more articles.....


pen icon Comment Entry
Subject
Your Name
Homepage
*Your Email
* Your email address is required, but not displayed.
 
Your thoughts....
 
Remember Me  

Please wait while your document is saved.