# Guess if a time is AM or PM

I'm currently in the process of writing a human date parser. By human date, I mean it should be able to interpret strings as "tomorrow at 2" and return a valid date depending on the current time.

The issue I'm facing is the automatic detection of missing AM/PM token. For example, if I receive an email that says "Lets meet tomorrow at 2", I know that 2 is likely to be, in fact, 2 PM. On the other hand, if the email said "Lets meet tomorrow at 11", 11 is more likely to be 11AM.

I guess most of the time, a simple comparison should do the trick. If the number is bigger than a certain limit n, we can suppose that the time is AM. If the number is smaller, then it is probably PM. In the sample above, 2 was more likely to be PM, and 11 was AM.

I know that a common work day is about 9AM-6PM, so numbers lower than 6 or bigger or greater than 9 are fine. We can easily guess for those. But what do I do with 7 and 8?

So the exact question I have is, where do I put this exact limit? When numbers approach 7~8, the limit becomes more ambiguous. I tried to search for previous documentation on this problem but couldn't find any. Is there any kind of convention about this? Also, in my opinion, the locale and/or timezone could influence this limit.

By the way, I'm not interested by non-definitive answers such as "In my opinion, 7 is afternoon" or "For me, 8 is morning". I'm really interested in documentation that could help me draw a definitive line.

Hope the description of the problem is understandable enough.

-

## migrated from stackoverflow.comSep 14 '11 at 11:03

This question came from our site for professional and enthusiast programmers.

Very subjective and context-dependent. No exact answer possible. – Tom Zych Sep 13 '11 at 18:12
@Tom: That's why I asked for documentation on the problem, and not opinions :) – Vivien Barousse Sep 13 '11 at 18:13
"Documentation" = "an opinion that someone wrote down and distributed". – Tom Zych Sep 13 '11 at 18:15
I'm interested to see some answers here. I feel like it would be beneficial to have some flexibility in your parser that reflects different "business hours", if you will. e.g. if it's marked somewhere that a company is open from 9-8, or a time zone difference prohibits the possibility of one party meeting at 7 am, then you know. Kind of makes you realize how ambiguous humans are in their language. – rownage Sep 13 '11 at 18:18
Even if there's a standard for this (I don't know of one), any solution is going to guess wrong in some cases. "Let's have a conference call at 7:00" is going to be ambiguous in a transnational company, for example. In an interactive system, you can ask the user for clarification, or at least make the default visible. If you're processing user input with no opportunity for feedback, there will be mistakes. – Keith Thompson Sep 13 '11 at 21:53

Very complicated. You won't successfully set a hard limit. Some thoughts:

1. Take into account awake time. Most are awake anywhere from 6am to 12am. Times outside of that are unlikely.

2. You'll have to use context. If the event is a meeting at 6, 6p is more likely than 6a unless the context is "breakfast", "wake-up", etc.

3. You should ideally build the system to learn what is most likely by allowing users to correct the times, if wrong, and having the system analyze the conditions and context under which corrections were done.

Like I said, this is very complicated. Google calendars does a bit of this. Examine that solution for examples.

I'd collect a bunch of keywords, associate them with AM/PM, search in the context phrase and use them to help determine correct time of day:

PM: afternoon, "after work/school", "from work/school", dinner, supper, evening, tonight, night, late, noon, "prime time", etc.

AM: morning, "before work/school", "to work/school", breakfast, early, wake, midnight, etc.

For something like "lunch", you'll have to have a rule like, if time is 12 or less than 6 it's pm, else it's am.

-
Thanks for pointing out that Google Calendar does it. After a few tests, they put the limit at 6. 6 is interpreted as PM, and 7 as AM. – Vivien Barousse Sep 13 '11 at 18:29

In addition to Jonathan's answer (basically an extension of 2) you could create some sense of context. Try to look for phrases "before lunch", "after lunch" and narrow down likely times. You could tweak the heuristics here a bit to make it more accurate as well. I think your best bet is to make it context sensitive.

As it has been stated, natural language analysis is a tough problem to crack.

-