Author: Wander Nauta Created: 2010-05-17 Type: Feature
- Introduction
- Motivation
- Rationale
- Implementation
- Issues
Handling dates and times is hard. Humans, for some reason or other, seem to have chosen a way of representing the flow of time in a way that makes no sense at all to a computer. Here's a little story to demonstrate the matter:
Courtroom, autumn 1997. "I didn't do it! Impossible!" says the suspected bank robber. "I knew you'd say that," says the Judge, "but why not?" "That's simple," continues the suspect, "I was in the Foo Bar! From two to three in the morning! It makes no sense!" Judge Dredd thinks about this for a moment, and instructs the policemen to find a witness.
The next day, the Foo Bar's barkeep is asked to go to court as a witness. "About last week? The robbery? Yes, yes," the barkeep says, "I saw that bloke..." - he pauses dramatically - "sitting in the corner. He ordered two whiskey, then left. He arrived around two and left some fifty minutes later. A bit of a shady guy, but no troublemaker."
The suspect's lawyer chimes in. "Your policemen have established that the bank was robbed at precisely half past two. I'll assume they made no gross mistake in something that easy. And you just heard the barkeep! He saw my client in his bar! Release my client at once!"
The Judge thinks about how his policemen could have made so large a mistake, when he hears a discrete cough from someone in the audience. "Yes?" he asks impatiently. A basement-dwelling programmer starts to speak. "Your Honor, that alibi is not as water-tight as you may think it is."
Why?
I was slightly puzzled by the contents of os/Time, which turned out to be slightly incomplete and a bit underdocumented.
The rock sdk contains a few functions to help with the handling of dates and times. Specifically, os/Time contains classes and functions to convert between different representations of moments in time.
To be really useful, however, programmers need to be able to work with time on a whole different level. Formatting times into strings, parsing times from strings, comparing times and time arithmatic are all features found in other programming languages, not because they are fun to implement, but because they are so widely used.
I think date and time handling should be implemented in ooc using two classes:
DateTime objects should contain information pointing to (usually) one single point in time. Possible functions include:
parse: an interface to strptime that doesn't segfault
format: similar, but for strftime
DateTime's constructor should take Ints, TimeT's and whatever Windows uses. It should also take Strings and pass those to strptime.
DateTime should internally store its value as what you could call a calendar date/time - TMStruct if you prefer - and convert to a numeric timestamp when needed. This is because, IIRC, conversions to and between timestamps can be lossy and/or problematic.
DateTime should also implement comparison operators and other arithmetic operators with a little help from...
TimeSpan objects should represent a stretch of time. An example could be 'one month, three days'. Functions you could think of:
parse: a custom function that converts a comma-seperated English description like the one above to a TimeSpan
toString: ...and back
TimeSpan's constructor should of course take Strings and pass those to parse.
The primary way of using TimeSpans however should be as the result of arithmetic with DateTimes.
Got the answer to the riddle yet? No? Ask wandernauta on IRC.
Joking aside, handling time is a feature of the operating system, and because of that differences probably exist between platforms. Ooc should try to abstract away those differences.