Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
User Journal

Journal cnoocy's Journal: If I were designing a DateTime object.... 10

Journal by cnoocy

Yesterday, we were discussing date/time handling at work, and came up with some thoughts. This entry exists to discuss those thoughts and possibly come up with a coherent proposal that can be used by developers and/or submitted to a standards organization.
The basic idea is this: DateTimes are worthy of the same kind of handling as IEEE floating-point numbers. They should have a defined range and precision, which should be well beyond expected useful values, and should include pre-defined, sensible constants such as "Not a Date," "Ever" (before everything), and "Never" (after everything). They should have standard mathematical operations (this may require a separate "Duration" type to go with what is essentially an "Instant" type) and behave appropriately. There are certainly aspects to this idea I have not considered. I am very interested to see others' comments on this.

This discussion has been archived. No new comments can be posted.

If I were designing a DateTime object.... More

If I were designing a DateTime object....

Comments Filter:
  • What is the reasoning in having "ever" mean "before everything", and "never" meaning "after everything"?

    If time is a number like, then it seems like "ever" would be the set of all points along the line, and "never" would be any particular point (or rather, no particular point, I guess) off the line. If you were treating all of this as complex numbers, "never" might be more like an imaginary number -- a point off the primary axis.

    Never seems like a close variant on "not a date", but I suppose it makes sense to keep them separate -- "never" is not a date, but things like "cat" or "semiotics" are even more lacking in date-itude. Or something. What about other semi-real date concepts? "Whenever." "Before a deadline." Etc.

    I wonder how much mileage you could get out of treating dates as just number line points or ranges (with "never" being the only non-silly example I can think of where something has to be represented & yet not be anywhere on the like). The tricky bit is recurring entries -- every Thursday in the afternoon might not be so bad to represent [saxophone here], but a holiday like Martin Luther King day (a certain Monday in January) is more subtle, and holidays pegged to non-standard-American calendars (Jewish, Chinese, etc lunar calendars) would be harder still.

    How all-encompassing does this have to be? On the practical side, there's a lot you can ignore -- lunar calendars for example -- in order to make systems for this manageable to implement. On the other hand, if a standard is to be established it might as well be done right from the outset rather than having extensions crammed on later (C -> C++, Ascii -> Unicode, DOS -> Windows, etc). Hmm...

    • I agree that "Ever" is a stretch, perhaps "First"? As far as never, it's because that's the obvious answer to "When will this happen" for impossibly future occurrences. Possibly "+Never" for the future and "-Never" for the past?

      In terms of all-encompassing, it can probably start as some non-alterable base, such as Julian day or epoch seconds, on top of which more complex DateTime parsing and handling can be built.

      I think recurring entries (let's call them "Events") can be a separate object class. They are not as central to the goal of what is essentially a near-primitive data type.
      • I was thinking that "when will this happen" and "when did this happen" as equally valid & likely questions to which "never" would be an appropriate answer, and I think there are probably good examples of situations where a "never" doesn't have an obvious "before now" or "after now" connotation -- though at the moment I can't think of an example.

        So, taking the complex number metaphor further than maybe I should, your +Never and -Never might map out to something like (+N + i) events and (-N + -i) [or perhaps (-N - i)] events.

        Ever, on the other hand, didn't really seem like a stretch to me -- it's just an event which happens to be true at all points along any conceivable timeline.

        Another class, which I forget if I mentioned, might be things that happen at no particular time, or that happen relative to some sloppily defined other time -- "finally get around to writing the Great American Novel", or "reach milestone, *then* work on next objective" for example. Things like this might be too hand-wavy to bother putting into a system like this, but then again, if you know that these events will/did happen and have to be accounted for somehow then you have to have some way to record them. Maybe we can punt & call them things like Jurassic, Cambrian, Cretaceous, etc -- i.e. "things that we know happened roughly in a given order, but will have to wait for 100 years after figuring this much out before radioactive dating will come along to figure out when exactly each of these vaguely specified eras happened."

        If you're trying to represent this in some kind of standardish software OO scheme, how about assuming that the primitive (or at least, relatively basic) data type is an Event, and that it must have a start and an end date. For instantaneous events, these two dates will happen to be identical; this case may be common enough that the object constructor defaults to giving the same values for start & end, but being able to handle non-equal start & end dates would be an built-in capability of the class. Then, as you say, recurring events can be a sub-class or whatever.

        Possible edge case: is it an error for an event to have an end date prior to the start date? In some contexts that might actually make sense -- countdowns for example ("election campaign") -- but would it make enough sense to allow this on a general basis?

        Object design was among my least favorite classes in school, so there may be obvious ways to improve on any of this...

        • Hmm.
          I think I like having Instants be the 0-length base class, mainly because they map much more easily onto basic math operators. I could see having an "Event" class as well, or even define it as a superclass for all sorts of events, from "between the 1st and 3rd seconds of 2004" to "Teatime every other Tuesday, except during the month of Ramadan in years with odd numbers in the Chinese calendar."
          As far as complex numbers, I don't think there's really all that much of a need. We don't have a real 2nd time dimension. I could see the following constants:
          Instants:
          First: Before all events. First.before(x) is always true.
          Last: After all events. Last.after(x) is always true.

          Events:
          Always: Event of infinite duration. Always.during(x) is always true.
          Never: Event of 0 duration. Never.during(x) is always false.
      • I agree that "Ever" is a stretch, perhaps "First"? As far as never, it's because that's the obvious answer to "When will this happen" for impossibly future occurrences. Possibly "+Never" for the future and "-Never" for the past?

        I don't see the need for First, but I do see the need for Never. When you are talking about dates, First only has relative meaning, while Never doesn't.

        In terms of all-encompassing, it can probably start as some non-alterable base, such as Julian day or epoch seconds, on top of which more complex DateTime parsing and handling can be built.

        The Perl DateTime project [sourceforge.net] is using Date::ICal [cpan.org] as its base; I believe that it uses julian days as its internal representation. One of the issues discussed was that the Epoch is broken -- it fails miserably for dates before 1970 (well, you can use negative numbers, but then it only goes back to 1902 or something), and, as we've found, dates past 2038.

        • I was actually thinking of the absolute meanings of "First" and "Last", that is, the first and last events possible.

          I like Julian dates, I also like Python's arbitrary-length integers. I was thinking on the bus this morning that it should be possible, in theory, to write a class that grabs precision as needed to access the absolute limits of possible instants.
          (i.e. Beginning of universe, end of universe, Planck time precision, but defaulting to seconds within 1-to-4-byte Julian days.)
          • I was actually thinking of the absolute meanings of "First" and "Last", that is, the first and last events possible.

            But, again, don't mix up events and times -- you can have times and dates without events.

            Of course, you probably didn't mean "event" as a specific action; but still, see my earlier comment -- it doesn't seem to make a lot of sense to talk about "before time" (first) in the same way you would talk about "never".

          • I also like Python's arbitrary-length integers.

            These are implemented as strings, and converted to ints when they need to do Mathy things, or BigInts if they're too big for the system's int type. Most other languages (i.e., Perl) don't implement ints this way.

    • The tricky bit is recurring entries -- every Thursday in the afternoon might not be so bad to represent [saxophone here], but a holiday like Martin Luther King day (a certain Monday in January) is more subtle, and holidays pegged to non-standard-American calendars (Jewish, Chinese, etc lunar calendars) would be harder still.

      Don't confuse duration and recurrance with dates and times -- they aren't the same thing, though they are related. You can have reasonable, extensible, robust handling of dates and times without even thinking about duration and recurance; in fact, I would suggest it.

      You all should check out datetime@perl.org -- there has been a lot of activity lately to standardize date handling in Perl, and, as a consequence, there has been lots of good discussion of exactly the points both cnoocy and babbage have made.

Slashdot Top Deals

Money is better than poverty, if only for financial reasons.

Close