Nah, you need a location; it's right there in the name "local" which implies time at a place. Saying "local time" alone doesn't always give sufficient detail in

Nah, you need a location; it's right there in the name "local" which implies time at a place. Saying "local time" alone doesn't always give sufficient detail in your example, because you want the device to be able to change it's location (its timekeeping context) while maintaining awareness of the difference between the device's local time and the local time of the thing you've recorded. "Local time" is basically never "good enough", actually. At a minimum, a time as you've described should include: - a location where you're tracking the local time - the destination local time at that location, from which you can derive most of the timekeeping context (time zone), usually - the current time of the thing doing the computation, in order to accurately compare device to destination time You then use those to get a UTC time that you can use to do things like a countdown. Or you can just make assumptions about those things and accept they'll be wrong; that's allowed but it's not usually what users want given we KNOW how to give them what they want.