User Centered

Good point about the North American calendar layout. As a Canadian I assume that the week begins on Sunday.

I picked up a (free) new wall calendar with weeks that start on Monday and it did confuse me until I checked the day order. I'm sure it will happen again.

Yes, it's not too difficult to make the adjustment. The hard part is noticing it.

If you mean the calendar you can enable to be viewed on right margin of blogs here at MyOpera, then I really think it is not worth to develop. I do not recall ever using it to access articles on anyone's blog, and if I did, then the day number was all that I was interested in, not the day of the week.

I recommend providing Archive view instead because there you also see the title Tags are also a useful approach when used right.

Sounds like you've got the same problem I was describing in this older post:
http://my.opera.com/usability/blog/2009/01/14/in-other-news-there-actually-is-a-company-that-still-uses-lotus-notes

Lotus Notes used the "Monday-centric" view and i kept clicking on the middle day thinking it's wednesday and ended up making appointments for thursday.

Instead of pointing the 238$ note, you can point to the 0$ RF note at W3C http://www.w3.org/TR/NOTE-datetime

another note, The US calendar is not the only one in use. The issue can become hairy. There are for example Japanese Imperial Calendar. Hebrew calendar, etc etc More calendars
http://en.wikipedia.org/wiki/List_of_calendars

This needs to be fixed. It is also a bigger problem if you have to select an entire week since a US based app would expect a Sun-Sat week.

just a little too Euro-centric

It's not Euro-centric at all. It's an ISO standard. Plain and simple.

If any other choice were made, it would mean it would be US-centric, Middle-East-centric, Euro-centric or <insert preferred geograpical location here>-centric. Not using the standard would mean there would be no interoperability.

jQuery UI being US-centric uses Sunday as the default, but offers an option for other days. Such an option would be a solution, but you have to take week number calculation into account too. And probably lots of other things. Which is why standards are so nice.

If you want something special, you can always roll your own.

For the sake of clarity, I'm talking about Opera's Desktop Application User Interface for <input type="date">, for the HTML5 spec.

Karl, thank you for the updated link. I'll probably add that, though Opera seems to have implemented the ISO Standard.

Originally posted by remcolanting:

If any other choice were made, it would mean it would be US-centric, Middle-East-centric, Euro-centric or <insert preferred geograpical location here>-centric. Not using the standard would mean there would be no interoperability.

Excellent response! This is exactly at the heart of my issue. First, I disagree completely I do believe "another choice" includes the suggestion I made about localization.

Second, standards are based on interoperability between applications, not necessarily the "standard" for how users should interact with the application. Even, Mr Kuhn, notes the Euro-centric commercial bias when discussing the 'week' implementation, "In commercial and industrial applications (delivery times, production plans, etc.), especially in Europe, it is often required to refer to a week of a year."1

What if the US were to impose their AM/PM standard of time on the rest of the world via their worldwide reach?

jQuery UI being US-centric uses Sunday as the default, but offers an option for other days. Such an option would be a solution, but you have to take week number calculation into account too. And probably lots of other things. Which is why standards are so nice. If you want something special, you can always roll your own.

I see your point here but I invite you to consider the totality with which a web browser might be used and how some applications might include simply getting the right date and no cumbersome week-number calculations. Flights, Timesheets, Bus rides, are all more dependent on the day-of-the-week than the week-number.

In B2B and internal computer programming I see the ideal of the standard but surely the ISO standard did not take into account individual users interactions and the risk for errors in changing their native expectations.

Originally posted by WillYum:

For the sake of clarity, I'm talking about Opera's Desktop Application User Interface for <input type="date">, for the HTML5 spec.

Now I understand. I missed the very clear example given.

Originally posted by remcolanting:

It's not Euro-centric at all. It's an ISO standard. Plain and simple.

I agree on this

Originally posted by WillYum:

What if the US were to impose their AM/PM standard of time on the rest of the world via their worldwide reach?

They do via their global Web sites, and that is the real issue here, that the rest of us are exposed to archaic proprietary formats. How bad can it really be that Americans get to see how the rest of the known Universe have agreed to work together the last few centuries?

I'm actually developing a timesheet app right now (hence all this time/date form focus) and the first thing my customer said to me was, "Oh, because everyone knows military time." 24-hour clocks are very non-standard here and for a fairly good reason. 12-hour analog clocks are still in use and the other reason is simply habit.

Technically speaking, I agree with the idea that behind-the-scenes there should be a battle and the best standard should win out! (or something) Then everyone should suck it up and use it.

But this blog space is about usability for the end-user, not for me as a developer. In your example, as soon as you see AM/PM you know, "Oh, those silly Americans," and can take corrective action (perhaps flip us the bird from across the pond), we don't intentionally trick you.

When you see a month laid out in it's standard table form and that implies a standard (by looking similar) but is actually different then it's a bit unfair to the user to expect them to always check to make sure the "sky is still up."

Besides, I don't think Opera or Europe is going to win any adherents by causing people to input the wrong dates and this is unusual for Opera because it has been, for me, notoriously usable.

You're probably right that the date picker should be localized, if nothing else to prevent American sites to unintentionally trick Europeans into picking the wrong day by using custom date pickers Seriously, all the top hotel chains use US date formats on their Web sites. One would guess that it's in their financial interest to change it based on IP address, but no...

Filed a bug, I thought is was just a comment. https://www.w3.org/Bugs/Public/show_bug.cgi?id=15668

From the Whatwg page.

"User agents should allow the user to set the value to the empty string."

"Note: The format shown to the user is independent of the format used for form submission. Browsers are encouraged to use user interfaces that present weeks according to the conventions of the user's preferred locale."

Sadly, it seems your bug-report was rejected out-of-hand:

The spec doesn't aim for theoretical completeness but for
addressing actual use cases.

I'm not sure how Monday vs Sunday isn't an actual use case. Sadly, W3C doesn't have a "dislike" button.

Borg, yes I would hate for all those poor Europeans taking advantage of the weak dollar to book a weekend and find themselves without a room on Sunday.

I do seem to recall that Google's calendar app asked as required setup what day-of-the-week my week started on. (Not suggesting this solution, per se, but perhaps some variation)

Yes in the US week starts on Sunday on calendars, tho I do know that in other parts of the world the week starts on Monday

Not sure if it would be a good idea to based the start of the week to use based on location

That is an excellent question. I would love to explore it if I get the time.

Originally posted by Chas4:

Yes in the US week starts on Sunday on calendars, tho I do know that in other parts of the world the week starts on Monday

Not sure if it would be a good idea to based the start of the week to use based on location

If it is a form on a bank website it would matter if you are selecting by the week. Which is an option.

I suppose what I've decided is that simply more robustness is needed. Yes, as a web developer I want the client to submit a proper and standard date format.

I also want users to see a calendar they are expecting to see. If that's M-Sun, Sun-Sat, or even Sat-F, I don't really care so long as the data my server receives has been normalized.

I don't like the idea of over-complicating a relatively simple thing (choosing a date) but I like even less the idea of oversimplifying it.

As it is, I decided to override Opera's date picker and use Jquery's Date Picker (which actually allows you to customize the first-day-of-the-week using the "firstDay' option)

I've never understood the idea of the week starting on a Sunday, since Sunday is part of the weekend so logically should be at the end of the week! It make no sense to me to split the weekend into two parts on a calendar, one day at the start of the week and one at the end. In the UK, some people consider Sunday to be the first day, others Monday, there seems to be no rigid standard.

In the end people should be shown the type of calendar which makes sense to them I suppose, though how it looks would seem to be a matter for user agents, which should pick up a user's regional settings. Quite a lot of software I've used lets you say whether your week starts on a Sunday or a Monday, my phone's calendar lets me choose for instance so I would expect a browser to as well.

Another issue is when weeks are numbered, where I work we number the weeks according to the financial year (ie. week 1 being in April) but all the appointment calendar software I've seen numbers them from January which makes the week numbering in the software not only useless but potentially confusing for people. So the placing of week 1 also needs to be user definable I think.

http://www.opera.com/company/investors/faq/#faq8

Week numbers is another global issue. The only week number schemes I know to be standardised begin on January 1. Simple? Not really because weekday trumps week number. A week begins on Monday or Sunday, but January 1 can be any day of the week, thus http://en.wikipedia.org/wiki/Week_number#Week_numbering

Communication protocols should be as unambigious and preferably simple as possible, so when a browser talks about a week number, day of the week, or whatever datum, the server knows what it is talking about. The ISO standards and their derivatives and equivalent specs are natural starting points.

This is necessary for cases like when you have a bank in Switzerland and a customer in the US. Whose localisation should be used, the bank's or the customer's. The UI might reflect the user's mores, but whatever is sent over the wire would have to match the bank's expectations.

For weeks the current spec states:

Originally posted by HTML5:

A week consists of a week-year number and a week number representing a seven-day period starting on a Monday. Each week-year in this calendaring system has either 52 or 53 such seven-day periods, as defined below. The seven-day period starting on the Gregorian date Monday December 29th 1969 (1969-12-29) is defined as week number 1 in week-year 1970. Consecutive weeks are numbered sequentially. The week before the number 1 week in a week-year is the last week in the previous week-year, and vice versa. [GREGORIAN]

In other words an ISO week all the way. The UI can or should be locale-dependent, but weeks have to conform to the spec. So the date control can show a calendar beginning on Sunday, but a week selector has to select a week from Monday to Sunday. In such a localised UI an HTML5 week will be on two rows, Monday to Saturday on the first row plus Sunday on the second row. The week numbering will be according to ISO as well.

Agreed Jax. The "data on the wire" absolutely must match the HTML/ISO standard.

Now the UI......

Yep, and yep, but this communication protocol, which in one sense HTML is, also puts in some constraints on the user interaction.

There is nothing to stop you from having a UI that starts weeks on Thursdays, or displays the days in a month in descending order from 31-28 to 1. But year, month, weeks, weekdays, and dates are hard defined. For most purposes this is fine.

Take the Thai calendar. These days it is really simple, you take the Gregorian calendar and add 543 to the year (for older dates it is more complicated, the year, just like in Hiroyuki's company, started April 1). So it is year 2555 now. The UI cannot use the (Gregorian) year 2555, any date comparisons would go high-wire, and the weekdays wouldn't match. The UI would have to show the year 2555 to the Thai user (unless he wants Gregorian dates of course) but send 2012 down the wire. You would need a special control for that, but it can be done. Since 543 years is a substantial period of time, the risk for misunderstanding is slight.

Weeks are a little trickier. As long as it is display only there is no problem, the problem arises when the author allows week selection or week numbers. The US client can use the Swiss bank just fine, Switzerland is using ISO already, but a Swiss client to a US bank would lead to complications if the bank want to allow their customers to pick a week.

In the case of the US client it would be a UI glitch (the calendar starting on Sunday would select Monday 13 to Saturday 18 on one row, then Sunday 19 on the next). It would look a little strange, but hopefully work.

In the case of the US bank it is a system discrepancy. The bank would expect a week to go from Sunday to Saturday (Feb 12-18), but the only week you can pick is running from Monday to Sunday (Feb 13-19). The Swiss client would just see a week row, while the bank will have the internal problem reconciling an internal 12-18 week with the web 13-19 week.

Week numbering is slightly easier again. The US doesn't use week numbers much IIRC. Germany use them a lot. In Norway they are popular in the bureaucracy and partly in the private sector. Of course if we can't agree when a week starts we can't agree on a numbering scheme since we are not talking about the same weeks. But even if we do agree on the weeks themselves we may not agree on which week is week 1 in a year. Your week 43 may be mine week 42. This problem we can solve though, much like with the Thai years, only with greater scope for misunderstanding. My user agent convert my week numbering to ISO week numbering, and then my user agent talks with your user agent, and it converts ISO to your week numbering. Problem solved if this is working, or problem compounded if it is not.

The trickier problem seems to me to lie with picking date ranges. Picking a single day is easy. A year and a month is also fairly standardised, a week less so, but for those applications that can handle ISO weeks it is fine. But there are other date ranges, a project or a vacation generally has a start date and an end date that don't match the year/month/week groups. If there were a single date range selector control, ISO year, month, week would just be convenient special cases.