Dates, Times, and User Intents

While almost any coding language you use has at least a data type for dates and times, they are still going to be frustrating to work with. This is even true if your framework of choice has numerous data types that are supposed to handle different situations. While the human mind can handle dates and times fairly well, there is a great deal of ambiguity in the way we express these things in language. This includes the way these things are discussed in planning. What makes this even worse is that you can often sound somewhat dumb when you ask for clarification around date and time issues, especially when talking to non-technical people. Because an intuitive understanding of time is very different from a technical one, almost any time (heh) that a date or time comes up, you really need to break things down further. Besides getting clarification on user intent with respect to dates and times, each approach requires careful attention to your infrastructure, system design, and the quirks of various parts of your platform. With these factors in the mix, code that “looks right” can be dreadfully wrong, have oddball edge cases, or need to be overridden on occasion. Additionally, because dates and times are physical measurements, you also need to take variations in precision very carefully. You also need to be aware of things that may cause you to have to adjust dates and times in some instances (largely because people have schedules). Depending on the intent of the user, even two otherwise equivalent datetime values may need to be handled in vastly different manners. Your users, and even different parts of your system, do not have the same view of time. A typical end user will want to see time expressed in their local time, as will a typical support person. However, if the support person is impersonating a user, they may be better off seeing the time in terms of the end user’s time instead of their own. Further, depending on the nature of your application, your end user might want to do different things when they are out of their normal timezone. System administrators and auditors will tend to want to view things in UTC time or in their local time, while external systems will likely either require UTC time, or will let you specify. While in the past we’ve talked about dates and times from more of a data type understanding, it’s also important to understand how dates and times are expressed by users and different parts of a system. While dates and times are complex enough on their own, it gets even more complex once you take into account the way that people (and outside systems) may wish to interact with your system. Far from just recording all dates and times with a single datatype that serves all purposes. Rather, you are going to have to consider your user’s (or system’s) intent and then how you are likely to need to work with date-time information. It’s more than just knowing a bit about data types – you are actually going to have to really think through what the data types may imply about business logic if you want to do well here. Episode Breakdown Just the date You might need just the date for things like getting someone’s birthday, scheduling payments by day, or for things like scheduling a day off. The key thing here is that the date being requested by the user must be respected and NOT altered by the system to some other date. Time zones can play havoc with things here. You may not want to collect the date as a datetime at all, especially if it is not going to be used for scheduling. Birthdays are a good example of this. If the date is used for sheduling, however, you will probably be better off to collect the day in the user’s timezone and then convert to your own for the scheduling purposes. You will want to display the date in the user’s default timezone when showing it to them,