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. 01/26/2023Better Running VirtualBox or VMWARE Virtual Machines on Windows 10+ Forgive me, Reader, for I have sinned. I has been nearly 3 years since my last blog entry. The truth is, I haven't had much to say that was worthy of more than a basic social media post -- until today. For my current work, I was assigned a new laptop. It's a real powerhouse machine with 14 processor cores and 64 gigs of ram. It should be perfect for running my development environment in a virtual machine, but it wasn't. VirtualBox was barely starting, and no matter how many features I turned off, it could ...... 
  2. 04/04/2020How many Ventilators for the price of those tanks the Pentagon didn't even want?This goes WAY beyond Trump or Obama. This is decades of poor planning and poor use of funds. Certainly it should have been addressed in the Trump, Obama, Bush, Clinton, Bush, and Reagan administrations -- all of which were well aware of the implications of a pandemic. I want a military prepared to help us, not just hurt other people. As an American I expect that with the ridiculous funding of our military might, we are prepared for damn near everything. Not just killing people and breaking things, but ...... 
  3. 01/28/2020Copyright Troll WarningThere's a copyright troll firm that has automated reverse-image searches and goes around looking for any posted images that they can make a quick copyright claim on. This is not quite a scam because it's technically legal, but it's run very much like a scam. This company works with a few "clients" that have vast repositories of copyrighted images. The trolls do a reverse web search on those images looking for hits. When they find one on a site that looks like someone they can scare, they work it like ...... 
  4. 03/26/2019Undestanding how OAUTH scopes will bring the concept of APPS to your Domino server 
  5. 02/05/2019Toro Yard Equipment - Not really a premium brand as far as I am concerned 
  6. 10/08/2018Will you be at the NYC Launch Event for HCL Domino v10 -- Find me! 
  7. 09/04/2018With two big projects on hold, I suddenly find myself very available for new short and long term projects.  
  8. 07/13/2018Who is HCL and why is it a good thing that they are now the ones behind Notes and Domino? 
  9. 03/21/2018Domino Apps on IOS is a Game Changer. Quit holding back. 
  10. 02/15/2018Andrew’s Proposed Gun Laws 
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.