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.


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. // ) 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:// )

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

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:


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:


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

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
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.
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. 09/04/2018With two big projects on hold, I suddenly find myself very available for new short and long term projects. In twenty five years, I don't think I've ever written an entry like this, but if you need the kind of work I do now would be a great time to get in touch. Both of the big projects I had lined up for late summer and early fall have been placed on hold and will be that way for a while. With the kids now all off at college and careers, I'm open to more travel than such than I have been in decades, but unless something else comes along, I'll be here working on updates to Second Signal and other things that ...... 
  2. 07/13/2018Who is HCL and why is it a good thing that they are now the ones behind Notes and Domino?We need to address some biases here. IBM has made a deal under which the Notes & Domino software and intellectual property is now being developed and maintained by HCL America. HCL America is part of the very large "HCL Technologies" company that has grown from its roots in India to become an 8 Billion Dollar company with a global presence in the IT Industry. You could be excused for initially believing, as many people do when they hear this, that "they've outsourced the code to India where they'll milk it ...... 
  3. 03/21/2018Domino Apps on IOS is a Game Changer. Quit holding back.BOOM. This will be as important for the platform as Traveler. If your company has ditched Notes and Domino, I feel sorry for you. For companies that do use Notes/Domino this is a game changer and Apple should be paying attention. Here's why: There are hundreds of little Notes client applications you'd never spend the time and money to build and deploy for your internal user base on IOS that we use Notes for all the time (those of us still using it). Now, those are suddenly ALL available on the iPad. ...... 
  4. 02/15/2018Andrew’s Proposed Gun Laws 
  5. 05/05/2016Is the growing social-sourced economy the modern back door into socialism? 
  6. 04/20/2016Want to be whitelisted? Here are some sensible rules for web site advertising 
  7. 12/30/2015Fantastic new series on Syfy called “The Expanse” – for people who love traditional science fiction 
  8. 10/20/2015My suggestion is to stay away from PayAnywhere(dot)com  
  9. 08/07/2015Here is one for you VMWARE gurus - particularly if you run ESXi without fancy drive arrays 
  10. 08/06/2015The Killer of Orphans (Orphan Documents) 
Click here for more articles.....

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

Please wait while your document is saved.