Quick Tip: Work Out a Server's Date Format From LotusScript
One of the first things I wrote about on codestore was a way to work out what format a Domino server expected dates in. Should they be mm/dd or dd/mm?
The code was a very simple one-liner of @Formula, which I've used in just about every application I've worked on since. You can see I've used it in the DEXT JavaScript object too (about 10 lines in).
What about when you want to do the same thing but from LotusScript? Not something I'd needed to do until last week when I was extending ('scuse the pun) the Ext.nd application by adding a date format property to it's base "session" Agent.
What I thought would be a case of multiple if statements turned out to be another one-liner after I learnt of the the Datenumber() function and used it in conjunction with "my" array-less Replace() shortcut. Here's the code:
Print |Ext.nd.DATE_FORMAT = "| + Replace(Cstr(Datenumber(1948, 12, 31)), Split("31/12/1948", "/"), Split("d/m/Y","/") ) +|";|
There's nothing more satisfying then solving a problem in one line of code. Yeah, I know it's on six lines. I did that to make it presentable.
The results is the following on my local, UK-based servers:
Ext.nd.DATE_FORMAT = "d/m/Y";
Or the following when I replicate the database to this site's server, which is in America:
Ext.nd.DATE_FORMAT = "m/d/Y";
Whether it's of use or not at least it's an introduction (for some of us at least) to the DateNumber() function, which I'd never seen before.
Then I got thinking about how to improve on it, as I can't work out if it's truly global or not. I know it works if the server uses / as the date separator, but I can only assume it works with "." or other variations. Can't see why it wouldn't though.
While messing about with this I was looking in the help files and discovered something else. Notes has an "International" class. Using that we could see what the server's date separator is. Not only that but it already has a property to tell us whether the server is MDY or DMY.
We could use it to write a function like this:
Function GetDateFormat() As String Dim international As NotesInternational Set international = session.International Dim BaseFormat as String If international.IsDateDMY Then BaseFormat = "d/m/Y" Elseif international.IsDateMDY Then BaseFormat = "m/d/Y" Elseif international.IsDateYMD Then BaseFormat = "Y/m/d" Else 'default BaseFormat = "d/m/Y" End If GetDateFormat = Join( Split(BaseFormat, "/"), international.DateSep) End Function
Although that's a lot of code isn't. I much prefer the one-liner, don't you?
And it would not work on a german server ...
because we normally have a "." as separator.
Are you sure about that Thomas? Which won't work? Surely both the above codes snippets would.
Working on the theory (as I understand it - not bothered to test) it should work with any date separator!
For the one-liner the call is, in effect, to:
Replace("31.12.1948", Split("31/12/1948", "/"), Split("d/m/Y","/") )
The result would be "d.m.Y" would it not?
After testing the GetDateFormat function above I can report that it does work well for YYYY-MM-DD as well (the format used in Sweden and in ISO 8601).
Thanks Mattias. What about the one-liner -- does that work too?
Doesn't the http://www.codestore.net/$preferences.nsf page allow the user to set the time zone and regional preferences? If these are set, does it matter what the server is set to?
I have javascript code that uses the browser to automatically set the DomTimeZonePrfM cookie, but haven't worked on the DomRegionalPrfM.
BTW, your server doesn't have the upgraded Daylight Saving Time files.
Hi Tanny. I've set the server to use the "server's locale" rather than any user preference. I find it's easier in the long run. Can't remember exactly why but the cookie approach didn't work for me.
Re: Upgraded DST. How do you know?
As expected the one-liner works too. :)
The following is printed:
Ext.nd.DATE_FORMAT = "Y-m-d";
Hi Jake, I knew that the codestore server had not had DST upgraded by going to http://www.codestore.net/$preferences.nsf and selecting Pacific time which gave me:
(GMT-08:00) Pacific Time (US & Canada); Tijuana
If you go to a server that has had a complete DST upgrade for Pacific time you will get:
(GMT-08:00) Pacific Time (US & Canada)
Tijuana now has its own setting which is:
(GMT-08:00) Tijuana, Baja California
I was on the DST conversion project at my company last in 2007. IBM fixed a number of errors that I found in their DST table. Part of the project included coming up with a way for web users to have their DST settings automatically set when they access a web page/site. I was able to create javascript code that does that about 98% of the time. When it doesn't choose the correct zone, it at least chooses the correct DST rule.
I would like to work on code that sets the regional setting too, but it hasn't been a priority since we are a US only company and currently only use US rules of punctuation.
Thanks Tanny. I'll look in to fixing it. Probably won't rush though as there aren't any business-critical time-orientated apps on here.
Hi Jake, I know you said that "Can't remember exactly why but the cookie approach didn't work for me." I'm curious to know why it didn't work. Does anyone else out there have experience with the DomTimeZonePrfM and DomRegionalPrfM cookies?
One of the incentives in using Java agents could better Locale handling for date, number, currency formats. Since Domino 8 supports Java 1.5 there are more in the offer. However Lotus Script looks like popular choice too...
Hi Jack,
I have agent which runs on webqueryopen event.
I got different result when used GetDateFormat() and the one liner. Here is my findings.
While I used GetDateFormat() , I got Y-m-d.
While I used Replace(Cstr(Datenumber(1948, 12, 31)),Split("31/12/1948", "/"),Split("d/m/Y","/")) in the same agent I got
m-d-Y as server date format.
Do you have any idea why I get two different dateformat for same server?
Thanks
Joy
Hi Joysuryo,
There must be something weird on your server whereby it thinks it's set to Ymd, so that international.IsDateYMD is true. No idea why though.
Jake