User Tools

Site Tools



This project is already fairly mature, so this page exists to hold notes about enhancements.

Github repo

Time/Date Parsing

Basic tokens can be implemented with strptime(), but (in Python at least) unparsed suffix data cause an exception which means we need to know in advance how many tokens to consume. This is the reason why we need both <date> and a <year> tokens, for example.

Phrases such as “next Monday” can be ambiguous, but they're very common so a reasonable interpretation is probably still useful. The table below shows the offset in days from the current day for each of the three phrases shown:

Day “last Wednesday” “this Wednesday” “next Wednesday”
Monday -5d +2d +9d
Tuesday -6d +1d +8d
Wednesday -7d +7d +7d
Thursday -8d -1d +6d
Friday -9d -2d +5d
Saturday -10d -3d +4d
Sunday -11d -4d +3d

Note the inconsistency where “this” becomes synonymous with “next” for the current day — this reflects the fact that I don't believe someone would ever say “this Wednesday” if they meant “today”.

The algorithms for each version are thus (assuming <weekday> and <current weekday> have been converted to zero-based integers where Monday is zero):

  • “last <weekday>”
    • <new date> = <old date> - <current weekday> - 7 + <weekday>
  • “this <weekday>”
    • if <weekday> == <current weekday>:
      • <new date> = <old date> + 7
    • else:
      • <new date> = <old date> - <current weekday> + <weekday>
  • “next <weekday>”
    • <new date> = <old date> - <current weekday> + 7 + <weekday>

A bare day of the week (e.g. just “Tuesday”) is always taken as the day of the current week (Monday-based), as opposed to some date parsing packages which regard this as synonymous with “next Tuesday”. This means it doesn't quite correspond exactly with any of the last/this/next interpretations, but that's probably OK.

ttrack/start.txt · Last modified: 2012/12/11 12:16 by andy