In some cases, the bot may have knowledge of the user's timezone. Is there a way to pass this knowledge to the bot framework so that it can handle certain date forms correctly - e.g. "tomorrow" & "yesterday"? Even things like "next friday" are sometimes sensitive to the timezone.
Currently, it appears that these are handled assuming the user's timezone offset is zero.
It seems that the chronic parser is unreachable so you can't really change anything to that. I see 3 solutions.
Solution 1: Create your own RecognizeDateTime class to work with utc time or however you want.
Solutions 2: When you get the date (in the validation method for example) add the utc offset to the time. This will preserve the right date, for utc times and local times.
dateTime += TimeZone.CurrentTimeZone.GetUtcOffset(dateTime);
solution 3: When the datetime is created by using a string like "yesterday", the day is correct but the time defaults to 00:00 or 12AM. To make this less sensitive you can just add 12 hours to the UTC time. This will preserve the day in almost all timezones. (All timezones above 12+ will have a problem. Luckily there aren't many people there.) (This is the solution I'm currently using for one of my solutions)
Perhaps this question should be broken up into two posts, but I currently have an API for a few business customers. I am currently using ISO 8601 timestamps with a UTC time zone to represent times. However, I don't like the idea of these timestamps being attached to any timezone because the times should be the same no matter what timezone you are in. 5PM UTC should be 5PM CST, etc...
I know that you can leave the Z off of an ISO timestamp, and it will be interpreted as whatever local time you are in. Is this ok practice? And if so, how do I do this in Ruby? I read the doc for the Time class and didn't see anything about this.
EDIT: Let me re-word this just a little bit, or atleast clarify something. The reason why I'm seeking timestamps that aren't attached to a timezone is exactly because I know that my client servers and API server will hardly ever match up. If a client is submitting an event with a time, that time needs to be ambiguously equal to the ambiguous locale specific to the event that the user is working on.
That's a mouthful...assume that I'm working on an event scheduler. Each event belongs to a storefront or location of a company. When times are being shown for a location, it is assumed that the times shown are in the timezone of the location, and for clarity's sake should never be shown at a time formatted to a user's local timezone. If I'm looking at the scheduler on the East Coast, but looking at events for locations on the West Coast, the times I should see should be local to the locations on the West Coast, not adjusted for my timezone.
I know a solution could be to simply store times with timezone information for the location its associated to. But the use case that a user would want to convert a time to their timezone is VERY rare, and I'd rather make implementing my API easier...this was actually my original implementation but implementing the API in many different environments and across multiple programming languages, it became clear that it is a hurdle to show times local to that timestamp's timezone for a lot of languages. If a user wanted to convert times to their local timezone I could easily store global timezone information for the location object itself.
I don't know what you mean by "the times should be the same no matter what timezone you are in. 5PM UTC should be 5PM CST, etc..". 5PM UTC clearly isn't 5PM CST!
Anyway, I don't think that what you are proposing is an ok practice. Suppose you leave off the Z and have a timestamp be interpreted as whatever local time you are in. Since this is a network API, the client and server might not be in the same timezone. When the client submits a "local" time, what does it mean? The local time on the client (if so, how does the server know what that is?)? The local time on the server? It's ambiguous. This is the crux of the reason why just about the only reasonable thing to do is to use UTC throughout.
What you can do is attach a timezone to a timestamp if it might be relevant. For example, "you should observe one minute of silence at 2012-11-10T22:00:00Z in honour of the soldiers who died in WW1" sounds weird because Rememberance Day isn't on November 10! "you should observe one minute of silence at 2012-11-11T11:00:00+13:00" sounds a lot better once you put that New Zealand time zone in there... In this case you can keep and timestamp (in either local or UTC) together with the timezone offset (e.g. store both of them together in your database).
It does, however, depend on what your times represent. For example, in "at equinoxes, sunset happens at 18:00" it makes sense to use an abstract time that isn't qualified with a timezone (it's true in every timezone, and/or you're talking about solar time). But attaching a date to this abstract time makes little sense, so I don't think you would be talking about ISO8601 in this case.
I'm working on an app that will be used by the public services (ambulance). Since those people work around the clock, they will realistically need to enter date/time values at ANY time of the day. Which also includes DST changeover times.
Now, when entering the time at the "short" day, things are easy. Simply any value between 3:00:00 and 3:59:59 is invalid. Problem is with the "long" day, where values in that same interval are ambiguous.
Is there any standard way/notation for entering time at that dreadful hour? Have you ever used any other workarounds, and which ones did your users find good?
Added: Also cloned on ux.stackexchange.
Allow the user to enter the localised time (i.e. whatever their PC clock is displaying) but save it in UTC. When you display them remember to use a localised time method and it will fix itself, see this SO Question for more details: How to display localized date and time information to web users with ASP.NET
I have a form that asks users to enter a start and end time for an event. For many years, we have allowed them to enter the times by selecting the hour (1-12), minute (1-60), and AM/PM from three drop down boxes. This has worked fine without complaints from customers. However, today I was hit with a request to change the input to one text box for the user to enter time in military time (aka 0000 - 2359). In my gut I believe this is a bad idea but am having trouble coming up with any hard facts.
What are the best reasons I can give that this would be a bad idea?
If there is a better solution for entering time, what would it be?
Also, FYI the users filling out the form run the gamut from very little skill with computers to advanced users. They are in no way military related.
Update: All my users are local and no other forms (web or print) use military time as the standard.
Three dropdowns are a nightmare usability-wise. You can cut these down to two by eliminating AM/PM and moving to 24-hour format, but still: a dropdown with 60 items is overkill.
I'd much prefer to enter time "manually", provided that these input boxes will be intelligent enough (say, they should be able to convert 18 to 1800, 0 to 0000, allow : as a separator, etc.). Plus do not allow users to enter incorrect data in the first place.
To answer your question: I see no reason to disallow your users to do what they want. After all, they are users.
Well, from a user interface standpoint, this could be a mistake simply according to some of Jakob Nielsen's user interface heuristics:
"Match between system and real world." If your users are not used to entering dates in military time, asking them to do so for your app can be distracting at best, and frustrating at worst.
"Error prevention" You are not eliminating error-prone conditions, but possibly introducing them.
There is also the question of why this change is being made. Are customers complaining? Is data coming in incorrectly? As mentioned by others, are your users used to military time? Any interface change should happen for a reason, IMO, because you're going to change the user experience and there will be ramifications for that; it's just a matter of how large those ramifications will be. My assumption is that data entry errors are supposedly going to be avoided -- but are they? Asking a user to enter a time as "XX:XX" and parsing out the semicolon (or, as Aaron Digulla stated, ANY non-number characters) and then converting it as needed seems less likely to result in errors than asking a user to enter a time in a format they are not used to using daily.
My concern would be that a user wants to enter 3:30 PM, and, while not paying much attention, simply enters 330. This is now 3:30 AM, and the user will never know the difference, because the app takes the information and happily assumes that this is what is meant. However, allowing the user to enter the time in "XX:XX" format and having an "AM/PM" selection makes much more sense.
As far as hard facts, well, I don't have them either. But if your boss/client won't be swayed by Nielsen's heuristics, I'm not sure what can change their mind.
Oh my.
My advice is to quit and find a different project.
We did a scheduling app for a "military customer" - and even they could not agree on what constituted "military time". Half of them wanted something called "Zulu Time" - the other half wanted "GMT plus offset" - then some wanted local time in 24h format. Contrary to what our contract specified, a Colonel insisted we use "Zulu" - we made the change for political reasons (in violation of our contract) - and then HE missed showing up for a scheduled event, because he thought it was in local time. Then contract management came down on us like a ton of bricks.
(never mind that the published schedule also used an obsolete "offset" that was a cold-war holdover meant to "fool the Russians").
In that this is just me sharing a war-story. . .
The real answer is to Elicit Requirements from your customer. Get those requirements SPECIFICALLY written into your contract. Make sure that the stakeholder who is actually writing your check, agrees. Develop to that specification exactly. When someone complains tell them to pay for a contract mod. You'll probably be changing this back and forth among many different settings for the next 10 years. You'll have steady work, and you'll understand why military contracts frequently go way over budget and are never on schedule.
"They are in no way military related."
That's a good enough reason for me. It's an uncommon format that, while not exactly "user-hostile," is nonetheless not the way most of us are used to seeing dates, and requiring your users to do the conversion in their head will lead to arithmetic errors eventually.
That said, drop-down boxes aren't great either. Best to go with 2 input boxes and an AM/PM dropdown, in my opinion.
It may not be a bad idea. Imagine the case where users must enter that bit of information lots of times, for example because they are in call support. Or they may find the dropdown boxes not usable enough, even after having tried them. They may prefer that other format.
It is usually a good idea to talk to the stakeholder and ask him: "Why do you want it this way?" you can then contrast their ideas with yours, but if yours are only that you have the "gut" feeling that this is not right, guess who will win the argument. The gut feeling is not a valid business argument - especially when the business is not yours.
So in short, do what your customer wants - just make sure that they understand their options well, and point out to them any inconvenience that they may have foreseen - once you find one, that is.
Honnestly, I think using AM/PM format is a bad practice, but that may be because I'm used to the 24 hours scale.
One reason against is that if all your users are used to the 12H scale, then most of them might still enter 1:00 instead of 13:00 for 1:00. Since the PM is not here, it will result in mistakes.
However, one good reason to do the switch is simply because it's the international standard.
Depending of what you want to put the emphasis (speed or functionality) you can use a time picker that would rely on regional setting to diplay the time in the user format or use a clock-like control. If speed is important, you might prefer a simple mask-textbox.
Hmmm, describing the 24 hour clock as "military time" and then noting that the users are not military makes me a more than a little twitchy.
It will depend on your users but I think that it is more than reasonable to expect people in contemporary society to understand the 24 hour time format and to be able to enter times using that format (given that I would - possibly naively - expect that format to be in use for bus, train, plane and other timemtables almost universally for the simple reason that its unambiguous). Perhaps this is not true worldwide - but it is certainly true across Europe.
That said, changes need to be made for a reason - "if it ain't broke..." is a very sound maxim for a working site and whilst I wouldn't ever willingly use am/pm for time entry I don't have a problem with use of dropdowns for time entry - especially as one can type "into" them. In this case I think that going from drop downs to text boxes is most likely an opportunity to introduce errors (although again it rather depends on the users).
I can see why you think this is a bad idea, silly users input wrong format etc.
However have you considered a jQuery Masked input box?
In my own frames, I accept times and dates in a wide variety of formats. When the field loses focus, I'll try to parse the input and format it into the "correct" or "official" format. This gives the user a nice way to enter the data and a visual cue when something is wrong.
For example, in a date field, I'll accept "1" as "01.12.2009" (current month+year). In a time box, I'll accept "1030", "10 30", "10.30" (i.e. I just filter out anything which isn't a number). "010409 1125" becomes 1. April 2009, 11:25am.
Few outside the united states knows the words "military time". They also prefer 24-hour format.
If you want globalization, you can do one of the two:
use accepted and de-facto standards, such as ISO8601 date format, 24h time and speak English
dive into the nightmare of the vast regional-based localization complexity (some unfortunate programmers have to do it anyway. Then they support AM/PM, unicode and never-showing-yellow-color for certain cultures)
I cannot believe how much consideration this idea has gotten.
Forcing your user to do things your way, because it's "more efficient" is a terrible idea.
Your forms should be both streamlined (power users can enter data quickly from the keypad) and comprehendible (first time users can navigate successfully). The conversion to 24 hour time will throw people immediately. I lived in Quebec for almost six years and still had troubles switching back and forth from 24hour time. DON'T DO THIS.
Just in addition to all the rest of comments you should thing about one more thing.
Programmers and designers usually think the client pays us just for creating what he tells us to... That's only half true. They pay us, even if they don't realize it, for telling them what they need, what's best for them.
Of course, the final decision is always theirs, as the pay, but if you feel it is wrong and you think you know the business model better than them, then do not blindly accept whatever they told you to do.
You might want to consider using the jQuery timepicker (or Telerik DateTimePicker in Time-only mode for WinForms) and also build in support, on the backend, for multiple formats in the event that javascript is disabled.
date/time input through select boxes is a horrible UI design.
but, if some of your users come from the few countries that stick to AM/PM for time format, then forcing the "military" format on them without assistance from the program is also bad.
use something like the jQuery masked input plugin.
if i was doing this, i would use a masked text input and a "PM" checkbox: if the value is more than 1259, the checkbox is disabled. otherwise, it's clear by default.
Why not use a TimePicker control of some sort?
You shouldn't force non-military users to user a strange to them time format.
In any case, assuming that all input is by logged-in users, you can provide multiple mechanisms (and certainly multiple ways if displaying time) and make the choice a user preference. But I'd strongly recommend that whatever you do, for any given user times should be entered and displayed in a consistent manner.
I need to let end users specify a time range, to be stored and used internally as a starting date/time and ending date/time. The range could be minutes or it could be days.
Has anyone discovered an interactive control that can handle this elegantly?
Most GUI toolkits have a calendar control, so I could specify "start" with a calendar for the day and a text field for the time...and the same for "end".
I could also replace the "end" controls with a single text field or slider that simply describes how many seconds/minutes/hours after start "end" is.
What I don't like about these ideas is how much clicking, typing, and more clicking is required to describe such a simple concept. Also I have to slap the user's hand if a time is typed in that isn't recognizable as a time.
Is there a cleaner implementation that I'm overlooking?
I tend to look at common design patterns for inspiration when I'm pondering problems such as this.
The Yahoo Pattern Library offers some potential solutions.
The UI Patterns site also give some suggestions, and is worth a browse.
For good measure, here's another solution at the Welie pattern library.
Another source of inspiration might be other sites and applications. For example, think of all the use-cases where recording short and long time time durations is required. As an example, company TimeSheet recording, company car mileage log software, task recording software, stopwatch applications, calendaring apps, etc. Then see how they've handled the GUI controls for capturing time ranges.
I haven't personally found a favourite solution for picking date and time. But, I think I'd want something like this.
User clicks to show calendar popup
Popup shows 2 side-by-side calendars (start date/time and end date/time)
Calendar 1 shows todays date, and the other also shows todays date.
Calendar controls allow usual navigation and selection of day month year.
Below each calendar is a hh:mm box, which defaults to the current time.
User can edit value in this time box using up/down arrows or by typing.
Alternatively, show an analogue clock below each calendar. It takes 2 mouse clicks to set time( click 1 for hour and click 2 for minutes).
Hope this helps
I am a fan of an old control I saw used WAY back in the 90's with Inventor (and later Open Inventor) on SGI machines (and then on PCs, etc): an infinite dial.
Some screenshots, a little on the small side, are here. Course, its been done on a variety of platforms since, including similar things on the iphone.
I think a date/time picker would work well with two dials, each representing an order of date/time magnitude. In ASCII art, with each dial between [square brackets] it might look like:
[20 Oct | 21 OCT | 22 Oct ] [11:15 .. 11:30 .. 11:45..]
or with 3:
[20 Oct | 21 OCT | 22 Oct ] [11 .. 12 .. 1pm] [12:31 .. 12:32 .. 12:33]
There are a number of variations you could try (vertical/horizontal, date/time, date/hour/minute, etc).
Dials, though somewhat rarely used, are a natural device for humans to interact with, and their infinite rotation option (unlike a slide which must always stop) suits dates/times well.
FWIW
User interface design is heavily application dependent. "Best" implies some kind of metric that can measure solutions. In UI design such a metric can be "home many clicks/key-presses does it take to complete the task?" where a smaller number is better. So once you've defined your metric you can start to sort solutions into good, better and best.
You also want to reduce cognitive burden for the user. If the user has to enter the final day on which a product can be exchanged based on a 90-day return policy then asking for start and end date would force them to do date math which is no fun. In this example a start date with a "delta" of x days would place less of a burden on the user.
Depending on you application you could consider and approach like the Google Finance time range selector on their charts: http://finance.google.com/finance?q=.dji
There is no single answer, it depends on the context. For many places good text controls are enough. Of course such things can still help by supporting pasting and some increase/decrease actions. Maybe it can even do some validation for the value.
Then there are places that need something more. Calendar can be really helpful for entering dates and some kind of slider could be used for time. (Lotus Notes calendar has a slider.)
My advise is:
Think what you need. Don't put complicated widgets to a less used dialog.
If you need these nice helpful widgets, check if there are ready made in the library you are using and take some time to see how others have done these.
Always have the text controls with support for pasting.
Check out the VisualHint date control. It can be configured a multitude of ways including a timespan. This would allow you to use one control instance to show the start time and another to set the timespan until the period is complete. The control also supports an extensible base framework so you could possibly combine both start/end or start/span into a single control.
Here are also some solutions: http://quince.infragistics.com/html/PatternView.aspx?name=Date+Time+Range+Input
Unless there is a more advanced time control in your GUI toolkit of choice, two calendar controls representing start and end is the most straightforward. Also, you need to decide how you want to use the information. For example, if you used a start date and an interval to increment that date, changing the start date wouldn't change the meaning of the interval. It really depends on what you're wanting to do.
One way I've seen work very well is using a gantt chart:
http://en.wikipedia.org/wiki/Gantt_chart
You can create a single line chart and then you can scale it across months, days, hours and minutes depending on how wide or zoomed in you make the control. The problem is I don't know of any control out there right now that does just one line, so you may need to create a custom one. You could possibly look for a gantt chart control and just do one task/item.
Observe what people are doing with your time range control. Then write it so that it's most suited towards doing what the people want to achieve with it. For instance, leave away past dates if inputting future dates only makes sense.
Jonathan Leighton has made a nice date inputter -element in jquery that I've found very nice for inputting dates. This is beneficial in a way that user can both input the date by clicking or type it in directly. The user also directly gets the hint about typing it into the box. If you couple this with some kind of timeline -object, you may actually go far afar. Just avoid making UI elements that are confusing or angering!
This comes in late, and it's not a control per se. I read this idea on a blog I can't find anymore (in fact, I found this post while trying to find it). The idea is to use the metaphor of a wall clock. Here's what I implemented for the fun of it. It's not a functional control. You could use something like this as a starting point for capturing times naturally. Three clicks at most, two most of the time. Only dials come close.
http://www.viridium.ro/clock-sample/
Use a HTML5-aware browser; that is, Chrome.