[HN Gopher] The Kobayashi Maru of Comparing Dates with Times
___________________________________________________________________
The Kobayashi Maru of Comparing Dates with Times
Author : holman
Score : 53 points
Date : 2022-02-12 20:18 UTC (2 hours ago)
(HTM) web link (zachholman.com)
(TXT) w3m dump (zachholman.com)
| bradleybuda wrote:
| The answer is no/no/no because you cannot define a general
| comparison operator between dates and times without additional
| context. It's possible that you can define a contextual
| comparison operator that works for your domain and the question
| you want to ask, but without knowing the application for this
| comparison it's pointless to try to make a general statement.
|
| My mental model for these kinds of things is that Times are
| instants and Dates are either:
|
| 1. Ranges (with the start and end Time depending on TZ and
| possibly other context)
|
| 2. Discrete cells of a calendar (which are mostly TZ independent
| - July 5th doesn't happen at the same time everywhere, but it is
| well-defined everywhere)
|
| Also, I've been writing code for 25 years and I still have no
| idea what a DateTime is.
| mikepurvis wrote:
| Isn't DateTime fairly consistently just a singular moment it
| time, either absolute (TZ specified) or floating and therefore
| locale dependent?
|
| Pretty sure these are the two cases which the python stdlib
| datetime covers.
| unleashit wrote:
| Sorry, haven't even read the article but I just love how the
| nerds are still preserving the memories and lessons of Star Trek
| II: The Wrath of Khan.
| grogenaut wrote:
| It was a main plot point in the modern movie series. What's the
| wrath of Kahn?
| unleashit wrote:
| Khaaaaaaan!
|
| Originally in the intro to the second star trek movie:
| https://en.wikipedia.org/wiki/Kobayashi_Maru
| derac wrote:
| My (naive) answer would be to localize any DateTime to account
| for any changes in Date due to timezone, strip the time and
| compare the Dates. I'd reckon a Date means any time in that date
| and is of lower specificity than a DateTime, rather than midnight
| on that Date. Is there any obvious issue with this in a situation
| where you might be (inadvisably) comparing a Date to a DateTime?
| axiosgunnar wrote:
| "Is Europe equal to France?"
| drewmol wrote:
| True
| dejj wrote:
| If you can compare apples with oranges, can you also compare
| oranges with apples?
| cema wrote:
| "It depends"
|
| First, are we talking about what _is_ or what _should be_?
|
| Second, what is the business logic behind the choice of Date
| versus Time to represent data (a data point or a segment) in the
| timeline? And is that logic consistent with the original design,
| and therefore with how the data have been collected?
|
| There is more, of course. Lots more, some touched upon in the
| article and comments.
| faangiq wrote:
| Just create a new time zone.
| franky47 wrote:
| A list of date/time/calendar quirks and oddities:
|
| https://yourcalendricalfallacyis.com/
| xorcist wrote:
| The specific question is strangely put. Why 12:00?
|
| In the generic case where one has conflicting data types to work
| with, including all sorts of lost precision, the boring answer is
| that it is context dependent.
|
| Direct user interfacing applications should follow the principle
| of least surprise, which for an interval search would be to
| always treat the value as inclusive when in doubt.
| [deleted]
| happytoexplain wrote:
| Without more context, they are incomparable. The author only says
| they came from a UI and a database - but what do they represent?
| And _what_ UI did they come from (i.e. what information did the
| user have when choosing the date[time] components, and how were
| those components encoded into a date[time]?). How are they being
| used _now_? I suspect the author is withholding some of these
| details to make a more interesting conversation (or to describe a
| "general case", but unfortunately there is no such thing as a
| general case for date[time]s).
| TillE wrote:
| Right. In a general case of a library casting types, the only
| thing that makes sense is to set the time to 00:00:00.
|
| In practical usage, you would probably want to slice off the
| times and only compare the dates, or use a fuzzier comparison,
| or just conclude that your input data is crap.
| d_watt wrote:
| Ultimately, this is the same problem as "is '04' > 3"? That is to
| say, you can only properly compare two things of the same types,
| and you can either implicitly or explicitly cast.
|
| The easiest option is that comparators should only work on the
| same data type, to avoid any ambiguity, leaving it up to the user
| to do explicit casting, and throwing errors if they don't.
|
| Of course, like integers and decimals, maybe it makes sense to
| have implicit casting, but it's unintuitive to me if
| "'2020-01-01' > '2020-01-01 12:000'" should be cast to two dates,
| two timestamps, or two timestamptzs. Even if a language allows
| implicit casting, it's probably an area where not doing it as a
| author is a smell.
| Waterluvian wrote:
| Over time I've come to firmly believe that code should rarely
| take shortcuts for me. Make me explain what I intend and error
| if you ever find yourself having to make a guess.
| alisonkisk wrote:
| travisgriggs wrote:
| I only read the question and am not aware what domain/language
| this is coming from.
|
| It seems they're talking about Instants with different
| resolutions.
|
| My answers are no, no, and yes.
|
| If we see what they're calling date as integers and times as
| floats, the questions become
|
| Is 4 equal to 4.5? No
|
| Is 4 between 4.5 and 200.5? No
|
| Is 4.5 after 4? Yes
| function_seven wrote:
| Is today equal to lunchtime? No, but also yes. "Today's lunch
| happens today" is a true statement, but "Today happens at
| lunch" is nonsensical.
|
| Is today lunch and a few months from now? No, but also yes.
| Parts of today are, but the entire "today" isn't within that
| window.
|
| Is today's lunch after today? No! It's _during_ today, not
| tomorrow or some other future day. But also yes! Lunch happens
| after the calendar has flipped to today.
|
| So we got Instants, Calendar Objects ("days", "weeks", etc),
| Durations, etc. Depending on context you could want some set
| operators to determine unions and intersections, or maybe you
| want simple numeric operators.
| happytoexplain wrote:
| "4" is, in _most_ contexts, implicitly a representation of
| "4.0".
|
| "2022-02-12" is _not_ always implicitly a representation of
| "2022-02-12 00:00:00".
|
| Sometimes granularity is omitted because it is zero, and
| sometimes granularity is omitted because it _doesn 't exist_.
|
| (and sometimes granularity that doesn't exist is represented as
| zero due to encoding limitations/mistakes).
| AprilArcus wrote:
| My intuition is that a "date" is a bounded range of times 24
| hours long. So we should speak about dates containing times,
| or dates subsetting, supersetting, or intersecting other time
| ranges.
| verve_rat wrote:
| Um, add in a daylight savings transition and that "date"
| could be 23 or 25 hours long.
|
| And that is not even getting into what a day means when you
| are trying to coordinate between NZ and the UK.
| CobrastanJorji wrote:
| I agree with you except on point 3. 4.5 is not beyond 4 because
| to me 4 represents the complete window of "4-5". 4.5 is neither
| before nor after it, it's within.
| cpeterso wrote:
| What date/time mistakes did UNESCO make that the Ruby
| documentation is referring to?
| lmilcin wrote:
| My favourite is battling with people who use 23:59:59.
|
| Where I work (banks and other financial institutions) there is
| frequently a need to check whether something happened within a
| particular day. Or maybe select records from the database for a
| day, or do some other kind of logic or filtering.
|
| For some unknown reason, most people decide that best way to do
| this is to take start date as the beginning of the period and
| then add to it 23 hours, 59 minutes and 59 seconds and use that
| as the end of the period.
|
| Explanations that they are missing a whole second do not seem to
| be working. People are absolutely convinced they are doing this
| correctly.
|
| I thought about this for a long time and I arrived at an
| explanation.
|
| It seems that some people use the time as a label for a portion
| of time. March 21st is a label for an entire day. 12 pm is a
| label for an entire hour that starts at 12pm and lasts an hour.
|
| If you think about it this way then yes, the day starts with a
| second labeled 00:00:00 and ends with a second labeled 23:59:59.
|
| Except that's not how most of the underlying software works.
|
| Another explanation is that people don't seem to be comfortable
| with the concept of selecting items from between 00:00:00 of one
| day and 00:00:00 of the next because they are seeing another
| date.
| function_seven wrote:
| And the scales just fell from my eyes. I'm guilty of this in
| the system I develop at work. Whenever I want to show the user
| all widgets that were made on the date they selected, I will
| just do something like DATE(widget_made) =
| :user_date
|
| Which does what I want and avoids the problem you brought up.
| But sometimes I have some more complicated logic that falls
| down if I try to compare datewise. So I manually create the
| DateTime ranges, and use 23:59:59 as the end of the range. So
| something like widget_made BETWEEN :user_date
| '00:00:00' AND :user_date '23:59:59'
|
| Anything that came off the line at 23:59:59.3421 will be
| excluded. Fortunately for me, I don't think that has ever
| actually happened. But now I know to be on the lookout, and use
| proper date-handling tools to ensure correctness.
| Waterluvian wrote:
| Once I have a datetime safely in my database as UTC, I don't need
| to record the original timezone, right?
|
| (assuming I'm not planning to need to know the history of the
| database entry)
| d_watt wrote:
| It depends on the implementation and definition of "datetime"
| in whatever you're working with. Taking Postgres as an example:
|
| date: the concept of a calendar date (Your birthday)
|
| timestamp: the concept of of a calendar datetime (You should
| get a new years kiss at 2022-01-01 00:00)
|
| timestamptz: the concept of a precise moment in history (This
| comment was written at xxx time utc)
|
| You can design a system where timestamps/datetimes are
| considered to be precise moments in time, utc, but that's a
| matter of the impmentation you're dealing with. Again, postgres
| does not assume timestamps as being in UTC (which has messed me
| up on more than one occasion).
| 0x0 wrote:
| Not if you are working with timestamps in the future, no.
| Someone may want a meeting to happen when the wall clock
| displays 4pm at some day in the future, no matter what unknown
| time zone rule changes will be introduced in the meantime. In
| those cases you will need to store the local time and a
| timezone identifier (or geographical identifier).
| rileymat2 wrote:
| It depends on whether or not the local time is meaningful or
| not.
|
| Say you are recording logins from a user. A suspicious login
| may be outside of work hours in local time. Without knowing the
| local time, you cannot apply this rule.
| kingcharles wrote:
| When you hit problems like these, the easiest solution is often
| to set fire to your computer and move to Tibet.
| phendrenad2 wrote:
| What do programmers in Tibet do?
| flobosg wrote:
| Compute all the possible names of God![1]
|
| [1]:
| https://en.wikipedia.org/wiki/The_Nine_Billion_Names_of_God
| atsmyles wrote:
| No/No/No definitively. Dates without times are ranges. If one
| person is born on 2022-06-01 12:00:00 and another person was born
| on 2022-06-01 13:00:00 then they have the same birthday
| 2022-06-01. It follows, that if you know that 2 people are born
| on the same day such as 2022-06-01, then it is unknown if they
| were born on the same time. So adding a default time to a day
| (such as 00:00:00) is nonsensical.
| noitpmeder wrote:
| Dates without times are... Dates? Aren't we talking about two
| distinct types here?
|
| Drawing examples from pythons stdlib there are (roughly) three
| types: dates, datetimes (tz naive), and datetimes (tz aware)
| phendrenad2 wrote:
| This seems like a Kobayashi Maru (a.k.a. a famous no-win
| situation test for budding starship captains in the Star Trek
| universe), but this isn't a simulator, this is real life. You'll
| never be in this situation. You'll always have more information
| about the sources for these dates/times. And that may give you
| enough context to make a decision, maybe not. But trying to solve
| the problem in the general sense is impossible.
| the_af wrote:
| > _You 'll never be in this situation_
|
| The article indicates the opposite: this is a real situation
| (it's explained why they are asking) and like Zach Holman
| states (somewhat exaggerated, true): unless your software has
| no users and is only one hour old, you'll find yourself in this
| situation.
___________________________________________________________________
(page generated 2022-02-12 23:00 UTC)