RSS Feed And A Domino Mystery
Back in June I added the RSS feed back to this site. That was about all I said on the matter. What I should have done is added a permanent link to it. Which is what I just did after been asked twice in the same week whether there is one or not.
And now a mystery. Something I've noticed, but never bothered investigating, is the difference in date formats for comments you guys add to blogs. My interest peeked yesterday when the issue was raised by Jim in one of his comments. Take those comments as an example. In order, we have the following responses:
- Paul (08/10/2003 06:41)
- Jim (10/08/2003 07:01 AM)
- Jim (10/08/2003 07:03 AM)
- Jim (10/08/2003 07:06 AM)
- Paul (08/10/2003 07:16)
- Jake (10/08/2003 07:17 AM)
Notice how Paul's are in one format and Jim's in another? The question is why?
Let's look at how the comments work. The user creates a "blogpost" document when they press the submit button. The name, e-mail and body fields are sent to the server. The date field is not. At no point does the browser tell the server anything at all about what time it thinks it is or what time-zone/country it happens to be in. The computed when composed text field, called "CommentDate", which is the string we see in the examples above, is computed by the server. It's formula is:
@Text(@Now; "S2T1")Where: S2 -> Date and time; T1 -> Hour and minute.
So, why the differences? I have no idea! Yesterday I put it down to "Domino being Domino" but today I am going to spend half an hour or so seeing if I can't work it out. You can help if you like. All you need to do is add a response to this blog. Include the following information in it:
- Browser
- Country
- Your local time
- Your date setting (e.g dd/MM or MM/dd)
- Any ideas you may have ;o)
Something tells me it will either be something very simple and, once again, I will look really quite stupid....
Update: Eureka! Thanks to Jerome and Mark Barton, we have the answer, in just under an hour. Jerome was first in there by showing that changing the browser's language setting, and hence the Accept-Language header, altered the format of the date. Then Mark stepped in with the definitive answer. Having read the article I have changed the following server document setting (Domino 6 only) to "Server's locale" and restarted the HTTP task:
Personally, I can't help thinking this should not be the default setting. The LDD article may well be called Making Web browsers look smarter but what does it make the crazy mix of date formats look like? Gibberish. Ahhh, Domino, I love you so.
Skip to the 
You can subscribe to an individual
To get the ball rolling:
1. Mozilla Firebird
2. UK
3. 10:39 AM
4. dd/MM
5. None
1. Opera 7.03
2. Spain
3. 11.46 am
4. dd/MM
1. IE 5.5 for Windows
2. The Netherlands
3. 11:42 AM
4. dd/mm/yyyy
5. It could be something with the clock setting being either a 24 hour clock or a 12 hour with AM/PM clock
1. Mozilla Firebird
2. UK
3. 10.45am
4. O/S date: dd/mm/yyyy (SuSE 8.2)
5. I have an issue with domino on different platforms every year with daylight time saving... could this be similar?
Thanks guys. Laurent, you've thrown a spanner in to the works there. You're date separator is - instead of /. Not seen that what before.
Is my assumption right that the server knows nothing about the browser's date settings?
1. IE 5.5 on windows 98 :(
2. France
3. 11:53 (24H clock)
4. dd/mm/yyyy
5. ? why should the server care about the client settings when it computes a field, anyway ?
Jerome. Exactly! It shouldn't. The only thing I can think of so far is that it really is a case of Domino computing date formats completely at RANDOM.
1. w3m (Text only)
2. Still UK
3. 11.01
4. dd/mm/yyyy
1. IE 5.5 on windows 98 :(
2. France
3. 12.01 (24H clock)
4. aaaa-MM-jj
5. it shouldn't, but i'm almost sure it does, at least partially... This is useless CPU usage, in my opinon :)
1. IE 6 on XP
2. Belgium
3. 12.04
4. dd/mm/yyyy
1. IE 6.0.6620.0000C0 on Windows NT Version 4.0 (Service Pack 6a)
2. United Kingdom of Great Britain and Northern Ireland
3. 11:00 (24HR)
4. OS format dd-mm-yy
5. You are avoiding the obvious conclusion that Notes is using the date from the client. Notes has always had problems with dates. I wouldn't be surprised if Notes is "creating" a datetime field based on the datetime that the "Name", "Email" and "Body" fields were created on the form being submitted _from the client_ ...
Also check for text conversions of datetime fields (an old trap.)
(Yes, there are a couple of R4.5x/4.6x maitenance point releases that still have Daylight Savings statr and end a week out of sych with reality.)
Patrick
1. IE6.0 on XP
2. USA
3. 6:11 AM
4. mm/dd/yyyy
5. Question: Is the date field hidden from the web? What date time will I see if it werent?
I could try to find the answer for my question easily, but once I started digging, I won't stop. So, I'll leave it here for now.
1. Mozilla 1.4 on windows 98
2. France
3. 12.12 (24H clock)
4. aaaa-MM-jj
5. maybe it uses HTTP headers like Accept-Language or Accept-Charset... But is cannot get the OS date/time settings (or am I missing something ?).
Patrick - When you say client I take it you mean the browser? My assumption is that the browser doesn't tell the server the time. The server uses its own settings to compute the date field. So, why the differences?
Veer - It's a strange one. The user POSTs a form whose ACTION is .../blogpost?CreateDocument&ParentUNID=... based on this trick - {Link}
The CommentDate isn't hidden from the web but it is only on this "blogpost" form and not the form that the user submits.
Jerome - My browser doesn't send any time or date headers but I will look in to whether or not others do.
A last one...
1. Mozilla 1.4 on windows 98
2. France
3. 12.12 (24H clock)
4. aaaa-MM-jj
5. Accept-Language =fr-fr
6. char coding = Western(ISO-8859-1)
I bet it's the Accept-Language sent by the browser... (look at my 2 latest posts, and it's the only thing i changed: 1st one was en-us)
Know any good bookmaker ?
You're a genius Jerome. That could well be the answer. How did you change that setting?
Do you mean book-keeper? i.e A "booky" to place a bet with? I'll give you good odds on this being the answer ;-)
Jake,
Is it anything to do with this
{Link}
1. IE 5.5
2. Sweden
3. 12:27
4. YYYY-MM-DD
5. Language Preference / Swedish [sv]
1. IE 6.0.28
2. Sweden
3. 12:32
4. YYYY-MM-DD
5. Language Preference / Swedish [sv]
Well, blow me. It's not Domino being Domino it's Domino being "clever".
Many thanks to Jerome and Mark. Should have known it would be some crazy new feature. I shall update the blog to save other people posting their detals.
What's still a problem is how to stop Domino doing this. I want all the dates and times in one format. It makes awful reading if they aren't...
1. IE 6.0.28
2. Sweden
3. 12:27
4. YYYY-MM-DD
5. Language Preference / English (United Kingdom) [en-gb]
I have the sam problem! Our solution was to use @Year, @Month and so on to "force" the date to be showned in one way!
@text( @Year( CommentDate )) + "-" + @text( @Month( CommentDate ))... and so on to get the "swedish" way to show dates... YYYY-MM-DD
Jake,
yep, I was refering to browsers, or thin clients (sorry for the confusion).
Interesting, reading the article it means that we, the readers, will see the date/times as you want us too (once you flick the switch and reboot the HTTP stack) ... so in effect this new Notes device has had the reverse effect. (Why you have chosen to use US format is another question altogether -- is that because you are using a Mac, and they don't have UK keyboards? -- Not that there's a great deal of difference between US and UK keyboards, just Shift-2 and -3 and the key next to the semicolon ...)
I wonder if you left the setting as default, and had the datetime created by us, the submitters, whether it would then display as in each users' timezone and format? (I take it we would need to fill in the preferences first: http://www.codestore.net/$preferences.nsf?OpenPreferences)
Why have you set your server to US Central time (GMT -6hrs) ?
Patrick
Patrick. In the old days, codestore was hosted on a shared server with many other websites. The server was in the US and hence under US time/date format. Not much I could do about it. Now, thanks to the generosity of my hosts, I have my own server. Still hosted in the US and still under their timezone. I could probably change it but then all the dates I've foolishly stored as text on documents created on the shared server would go all screwy.
Domino and dates are a pain. To keep things as simple as possible I've left it at US settings. Most people expect and understand these.
What I would give to be running this site on LAMP with SQL datetime columns and PHP's amazing date formatting capabilities...
I think the date formatting capabilities with the Format function are pretty good. In my DBs I use a function 'GetServerTime' with the Format function included so I don't have a problem with dates in one database used in different countries and with clients on different OSes.
I'm very impressed that the Domino community has rallied round to find the answer on this one. Ironically (or is it, Jake?), this whole discussion has left me out because of my time zone. While you clever people were submitting suggestions I was sleeping like a baby (ie drooling a lot).
I, of course, knew the exact answer, and was going to say the same thing as Mark. OK, not really.
So, is the date fixed now, so the date/time formatting is consistent?
And how come most of your readership is in Europe?
And you try telling me there's not much different between American and British keyboards. Have you ever tried moving to typing '@Functions' on a US keyboard...? The @ is above the 2. I am starting a pressure group to ask IBM to rename them '"Functions', so that my syntax errors become less of a problem.
Jim. Irony? Not sure!
Since I restarted HTTP the dates seem to be fairly consistent. Fingers crossed, this has fixed the formatting differences.
Nor sure most of my readers are in Europe. As you said yourself, America was in bed. Australia had probably left work and so only Europe was sat in an office at the same time as I with nothing better to do.
Next time I'll post similar things at midday to give you an equal chance ;-)
Jim,
Like different coding practices, I don't mind what the details are (i.e. where the blinking symbols are mapped too) as long as they're consistent.
I had to get used to the UK keyboard when I landed in the UK, as Australians use the US keyboard ... (I was doing a lot of "Functions) And this is also why I never bothered to get a DVORAK keyboard (even though IBM and others would supply them for the same price) ... Reminds me of all the annoying coding practices I have to come along and interpret / fix ... oops there goes the can -- worms EVERYWHERE.
;o)
1. IE 6 XP
2. NZ
10:46 AM
dd/mm/yy
Want to know why.
Surely, Domino got a lot of problems with "dating" ;-) But isn't this case your fault, some way? Keeping data type of date as string is always tricky. Why don't you keep this just as a DATE type?? Then you can do a lot of things when presenting data - especially with @Text function. It will be realy nice, when I see time in 24 hours, and you in your strange 12 hours format!
Of course, there are cases, when you must keep date as text but, as LL mentioned, you have to keep it in standarized format, which "S2T1" is not. But, as you already know, you must do standarization job by yourself. For me, who quite often have to "fight" against US or EN settings, it's a big lack of Domino, that @Text and Format$ functions don't operate with any of standard (ISO8601, ...) date-time formats ;-(
Jake,
Coming to this a little late, but surely fixing the date format to US is not the correct solution. Ok, so you have a fixed format of date, but with readers in many different locales that may be confusing (ok, so we all fall back to US mode when using the web, granted).
I would have thought that the relationship between the browser locale and server locale would have done the following. Note that timezone and date/time formatting are two different things here.
1. When posting data to the server, Domino records the client locale as part of the date/time, so that it has the option of showing the date/time in client specific format. You should be able to get a format of date that at least shows the timezone as the clients, not the servers.
2. When displaying stored values, you should be able to choose between server zone or client zone. ie. if I store a document at 12:00 GMT+0, and a US EDT client sees that time, they should see 07:00 GMT-5 (or 07:00 EDT). That way, the client can easily see if the post is time relative to their locale.
3. Date formatting should be at the client locale. In UK/US, we like '/' seperators between date components, but Europe likes '-'. In US they like mm/dd/yy, Europe likes dd/mm/yy.
What I'm getting at is that you may need to play with some of the advanced options for the @text function (Zx options), or just use the column date/time formatting properties in the view (i.e. let the view convert it to text).
The best case is when Domino is able to format to the client expectations, not the designers expectation (or rather the designer should be aware that diffent people like different things!).
Cheers
Dave
Dave - All I wanted was for it to go back to the way it worked when I was using R5.
The list of responses you see are part of a view. Hence it wouldn't be possible to show the client their prefered date format. It's one or the other. It's US style in keeping with the fact that the site began life on a shared server *in* the US. I don't like it but that's the way it is.
There is no content in your rss feed..