11 ms·

The Kobayashi Maru of comparing dates with times

132 points by holman 5y ago

faangiq 5y ago
Just create a new time zone.
wbport 5y ago
This site finds the midpoint between date/times as well as the difference between them. Also, time units can be added or subtracted from one date/time to get another. All of this is done through the JavaScript Date object which leaves to trace of the original time zone in arriving at the offset in milliseconds since 1970. If doing the difference between dates in days, round the difference to the nearest day to avoid problems with daylight savings time not being in effect for one of them. https://wjporter.com/misc/MidPoint.htm https://wjporter.com/misc/MidPoint.htm
rlhamil 5y ago
How about this: a date, or indeed even a time, is either of the shortest unit used in calculation at some moment (say by convention, the start of the date or time expressed perhaps down to nanoseconds); or it is a range, from the start of the date or time (expressed in terms of the shortest unit used in calculation, unless you want to fiddle with going down to Planck times to allow for future increase in precision) up to but not including the start of the next increment at the stated precision (for a time in seconds with a minimum resolution of nanoseconds, the billion nanoseconds starting at the beginning of the second). So,an hour range starting at a half hour boundary might fall entirely within a day, entirely outside that day, or half in that day and half before or after it. All of that neglects time zones, or assumes they're at most recorded for local convenience and/or historical purposes but converted for calculation into UTC or the like. So, for instants, either they're equal or they're not; but for ranges, they could be equal, or a smaller range entirely within a larger, or partly overlapping, or disjoint. Pick whichever model (instant or range) works best, and be consistent thereafter, and at least the surprises shouldn't be too surprising.
derac 5y ago
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?
kingcharles 5y ago
When you hit problems like these, the easiest solution is often to set fire to your computer and move to Tibet.
- phendrenad2 5y ago
  What do programmers in Tibet do?
  - flobosg 5y ago
    Compute all the possible names of God![1] [1]: https://en.wikipedia.org/wiki/The_Nine_Billion_Names_of_God https://en.wikipedia.org/wiki/The_Nine_Billion_Names_of_God
  - dxdm 5y ago
    They have different problems that will make them try to leave Tibet, I assume.
phendrenad2 5y ago
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 5y ago
  > 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.
  - phendrenad2 5y ago
    No, the article doesn't reveal anything about where this data comes from, other than the vague "user input vs database" which is useless. So their problem is real-world, and has a solution. We're supposed to solve the problem without the benefit of the context that they have, which makes it a contrived academic problem, which was my point.
unleashit 5y ago
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 5y ago
  It was a main plot point in the modern movie series. What's the wrath of Kahn?
  - unleashit 5y ago
    Khaaaaaaan! Originally in the intro to the second star trek movie: https://en.wikipedia.org/wiki/Kobayashi_Maru https://en.wikipedia.org/wiki/Kobayashi_Maru
    - efitz 5y ago
      "I don't believe in no win situations."
    - Izkata 5y ago
      There was also a whole episode of Star Trek: Prodigy (a kid-oriented series) centered around it a few weeks ago.
axiosgunnar 5y ago
"Is Europe equal to France?"
- drewmol 5y ago
  True
cema 5y ago
"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.
deleted 5y ago
[deleted]
franky47 5y ago
A list of date/time/calendar quirks and oddities: https://yourcalendricalfallacyis.com/ https://yourcalendricalfallacyis.com/
happytoexplain 5y ago
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 5y ago
  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 5y ago
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 5y ago
  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.
travisgriggs 5y ago
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
- happytoexplain 5y ago
  "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 5y ago
    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 5y ago
      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.
      - AprilArcus 5y ago
        Good point! ISO 8601 dates should support timezones. Then a 24-hour "date" could only be in one of standard time or daylight time.
      - Izkata 5y ago
        To really get confusing, let's add in leap seconds. They're added "as needed" and it looks like our most recent one was in 2016. https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second
Waterluvian 5y ago
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 5y ago
  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).
  - wiredfool 5y ago
    Dates from times are a minefield. I just had a long-standing bug come to the fore because I shifted a view to a materialized view, and embedded deep down in it was a date cast from a time stamp with tome zone. When running as a view, everything was done in the user's time zone (because tits set per connection). When it’s a materialized view, it's he refresher's time zone. This led to some inconsistencies, as the server is properly but inconveniently in UTC.
- 0x0 5y ago
  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 5y ago
  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.
bradleybuda 5y ago
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 5y ago
  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.
  - bobbyi 5y ago
    1:30 AM on whatever date we "fall back" for DST isn't singular in my timezone
    - Laremere 5y ago
      It depends on what you mean by timezones. 1:30am Pacific Time isn't well defined, but 1:30am PST and 1:30am PDT are.
      - PowerBar 5y ago
        Until daylight savings time ends and it's 1:30am twice. Time is hard.
      - danbruc 5y ago
        Those two things are called the time zone - a geographical area that has and had the same time all the time - and the zone time within that time zone which might change from time to time, for example regularly because of daylight saving time or kind somewhat randomly because people change their mind about which time they want to use.
cpeterso 5y ago
What date/time mistakes did UNESCO make that the Ruby documentation is referring to?
- tasha0663 5y ago
  https://en.wikipedia.org/wiki/World_Book_Day https://en.wikipedia.org/wiki/World_Book_Day
lmilcin 5y ago
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 span of time of unit length. 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, etc. 2021 is a whole year. And in some contexts it makes sense. Way say something happened on 12th of January -- we use Jan, 12th as a label for an entire day that we would otherwise have to denote with two timestamps. But in some contexts what we need is an exact point in time, a timestamp. And here is where a lot of people just don't think / can't recognise a difference between timestamps and labels for a span of time. If you use a wrong model 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. Most software in this case expects two exact timestamps to denote the end of the span of time. And 23:59:59 is just 1 second shy of the actual end of day which means that, even if we are missing an entire second of the day, most of the time everything seems to work fine. Unless you are large bank and you have millions of transactions all over the clock that have to accumulated exactly. Then yes, it makes a lot of difference. 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 5y ago
  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.
atsmyles 5y ago
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 5y ago
  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)
  - Izkata 5y ago
    > Dates without times are... Dates? Aren't we talking about two distinct types here? I assume this is a response to specifically this part: > Dates without times are ranges. If we're talking conceptually about general date/time/datetime comparisons, not pegged to a specific programming language or type system, I agree with it: Dates are a 24-hour range.
    - NateEag 5y ago
      Caveat: The date's range isn't always 24 hours exactly. Leap seconds can make it slightly longer. A daylight savings change makes the date's range 23 or 25 hours, depending on the direction. I would not be surprised if someone popped up with more edge cases I haven't thought of. Dates and times are crazy.
      - PeterisP 5y ago
        If you're treating dates as ranges, then even ignoring the timezones and daylight savings it still doesn't mean that a date implies a range from 00:00 to 24:00 - the mapping is inherently domain-specific and thus depends on the particular interpretation of that date field (thus it's nonsensical to expect a generic answer/comparison rule for "dates" i.e. all dates). For example, in the domain of financial settlement, a future date of 2022-03-03 would imply that the event must happen by the end of business day of 2022-03-03 (and thus an event at 23:00 of 2022-03-03 would be too late and would map to 2022-03-04 instead); and in a similar manner, the appropriate date for any events happening in the middle of a sunday would be either monday or friday depending on what your rules are, as the effective date which you would be using to calculate the number of days between two events (for e.g. interest) in may jurisdictions has to be a business day; so two events timpestamped five minutes apart might need to be treated as if they are on the same day, different days, or in some cases many days apart (e.g. with a combination of Christmas + weekend). Different domains will have different rules; the generic concept of "date" is too vague to define an universal comparison operator and you have to look at the meaning of each specific date field/variable and expect different date fields/variables to need different semantics.
xorcist 5y ago
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.
dejj 5y ago
If you can compare apples with oranges, can you also compare oranges with apples?
alisonkisk 5y ago
gregwtmtno 5y ago
I never understood why programmers have such a hard time with time. There are two and only two pieces of information you need to work with time: seconds past the epoch and location. Everything else is applying legal and social context to the actual data. Here both of those pieces of information are missing on all three questions, so no answers can be given. Any answer to these questions makes assumptions or deductions about those pieces of information.
- zabzonk 5y ago
  > Everything else is applying legal and social context to the actual data. It's that "Everything else" that programmers have to deal with.
- fknorangesite 5y ago
  > Everything else is applying legal and social context to the actual data. And then you just draw the rest of the owl.
- DaiPlusPlus 5y ago
  > There are two and only two pieces of information you need to work with time: seconds past the epoch and location. Everything else is applying legal and social context to the actual data. Date-of-birth? Calendar-quarters? Computer-local time? (No location, only the computer's UTC offset).
- shanxS 5y ago
  I am with you but you missed a key issue of comparison: granularity. Unix Epoch is by definition at granularity of seconds. How do you compare 2 epochs where one is in seconds while other in milliseconds. We sort of end up in same comparison game.
al_biglan 5y ago
No. No. No. Dates are to Integers as Date+Time is to Floating Point. You (we) -want- to compare them, but you need something akin to a language level specification for these. Otherwise, it is all what you are trying to do/what problem you are solving. Excel (where I suspect 60% or more of this nonsense lives) at least has a clear definition (both are floats, so you can do the comparison). Otherwise, "Down the Wat-hole" for what to expect.
munch117 5y ago
The CS answer: bottom, bottom and bottom. The static typing answer: type error, type error and type error. The dynamic typing answer: exception, exception and exception. The philosophy answer: category error, category error and category error.
lukev 5y ago
I am a little shocked that neither the blog post nor the twitter discussion nor any of the discussion here clearly identifies the missteps of this approach beyond alluding to a "category" or "type" error (which is correct, but not particularly informative.) The issue here is around the semantics of the mathematical operators. It isn't even really about the types to which they apply; there are systems where `=` is well defined on heterogenous types. The reason the answer to all these questions is a clear "no" is that they do not satisfy the core properties of the operators. For example, take equality. Equality in almost all mathematical constructs means that it supports substitution, is symmetric, transitive and reflexive. There are also well defined properties for the concepts of `greater than` and `less than`. So, no, the OP's conclusion "Literally we’re all just making it up" is incorrect. You cannot use the operators `=`, `<`, and `>` between dates and times because they do not satisfy the core properties that define those operators. (I guess you could try to document an alternate definition of equality without the symmetric property in your documentation but... good luck with that not leading to massive confusion.) Where you can just make it up is to define new operators as you actually want them to be. It's not `=`, it's `myDateTime=()` and then you're free to write the definition of that yourself. As long as you're consistent in the UI of how you present it (don't pretend it's vanilla `=` to the user!) you will at least be telling the truth. It may not solve all your problems but at least you won't be feeding any more to the fires of confusion, which you will as long as you keep pretending it's possible to make `=` mean something that's not reflexive.
- karpierz 5y ago
  I'm not sure I follow. If I define a date MM/DD/YYYY as equal to the time MM/DD/YYYY 00:00 GMT, which of the equality properties am I lacking? Similarly, if I use that definition of equality to convert the date into a time, and then compare it, can't I get '>' and '<'?
  - lukev 5y ago
    Well it depends on if you have a type system that distinguishes between "date" types and "instant" types. If you only have instants, then sure, you could do what you're saying, but the context in which the question was poised seems to imply that "dates" and "times" are separate. And if you do have separate "date" and "instant" types, you lose the property of substitution: f(x) = f(y) if x = y for any arbitrary function f.
IgorPartola 5y ago
The questions do not make sense so stop trying to ask them. It’s like asking if 2022-01-01 is an orange. Generally speaking you want context of what the date or datetime is being used for. If you want to know when Christmas takes place you will use a date: it does not take place on 2022-12-25 00:00:00 through 2022-12-25 11:59:59 because this would require a timezone and Christmas takes place at different UTC times around the globe. But you can reasonably say that Christmas takes place on 2022-12-25 and leave it at that to let the implementation of whatever program figure out if it is or is not currently Christmas based on the information it has about time and timezone.
- bricemo 5y ago
  I think the point is that the nature of software is that these nonsensical questions are “asked” by the code all the time. Data migration, different teams using different formats, user interfaces with imperfect translations, and other scenarios all result in these silly questions popping up. And in the middle sits an engineer who needs to decide how it will work.
  - IgorPartola 5y ago
    And my point is that if you don’t understand what the data field represents, don’t make comparisons against it. You must understand the context and then use the data. Otherwise you’ll ask nonsensical questions and get nonsensical answers and then be surprised.
- karottenreibe 5y ago
  Actually, in Germany Christmas already starts 12/24, so even this seemingly simplistic example is more complex of you support the entire world. Dates are hard.
  - skissane 5y ago
    Added to that, in some (but not all) Orthodox majority countries, most notably Russia, Christmas is on 25 December by the old Julian calendar, which is on 7 January by the current Gregorian calendar (which everyone uses, Russia included, for civil/commercial/everyday use). It’s Gregorian date moves forward by one day every century (except for every fourth century, when it doesn’t.) Some of the other Orthodox Churches (such as the Greeks) technically celebrate Christmas, not using the Gregorian calendar, but rather the “Revised Julian” - which happens to be identical to the Gregorian until 2800. I wonder if, come 2800, they’ll remember to move the date of Christmas, or if they’ll think “there’s no point to it, let’s not” (assuming of course that both they, and humanity as a whole, are still around in 2800)
anononymous5 5y ago
ok, my logic. Dates are Intervals of Timestamp (I put uppercase for clarity). A Date is [01/06/2020 0h0m0s..23h59mn59.999s] A Time can be seen as an Interval of Timestamp, albeit of length 0 A Time is [01/06/2020 12:00:00.. 01/06/2020 12:00:00] With these definitions, it's no (interval are different) no [01/06/2020 0h0m0s..1h59mn59.999s] is not included no the interval is fully included
nescioquid 5y ago
Isn't this just a matter of being clear of inclusive or exclusive ranges? Perhaps this is merely a provocation that the general perception of exclusivity or inclusivity rests in the casual programmer's perception (rather than the specification of which I confess ignorance)? Or is the provocation in measuring the contour of a coast? Can it be measured more precisely (surely it can)? In which case is the provocation one of mere precision? Or is the provocation one which asks how many fairies may fit on the head of a pin?
mdoms 5y ago
What is Kobayashi Maru? It's mentioned in the headline and then never again in the article, and never defined.
- addaon 5y ago
  https://memory-alpha.fandom.com/wiki/Kobayashi_Maru_scenario https://memory-alpha.fandom.com/wiki/Kobayashi_Maru_scenario
ineedasername 5y ago
I deal with this on a regular basis, and my approach is straightforward: I don't compare them. If a have a date on one side and date-time on the other, then I am missing the data necessary to make a comparison. The question seems like a non-sequitur because the implied question is "how do you compare two variable when one of them does not have the data needed for comparison" The only question in circumstance like this is whether or not my requirements allow for-- or can reasonably be modified-- to strip off time and only compare dates. If time is an inherent requirement to the project then the response I give is simple: "Then begin collecting time data."
- dudeinjapan 5y ago
  This is the correct answer. If you want to ask "Does a given date contain a time?", you find the start and end of that date in the relevant timezone and check if the time value falls in that range.
mdavidn 5y ago
This article doesn’t even delve into time zones. Each UTC timestamp maps to one of two dates, depending on the context of the user or the data. This is important in financial systems. Transactions in Hawaii can legitimately land in a fiscal period that has already closed in New York.
wwilim 5y ago
.NET now has DateOnly. I haven't had the opportunity to use it yet, but I have great hopes for it.
pygy_ 5y ago
Type error. A `date` is a time interval (from midnight to midnight in a given time zone). One could argue that `time` values in computer programs also cover a span, even if it is infinitesimally small for most purposes. The correct operation to compare intervals of varying lengths is not equality, it is either containment or overlap.
- hanche 5y ago
  One could argue that a date is a region in spacetime. It starts at the dateline, spreads eastward, and ends at the dateline some 48 hours later. (Edit: 50 hours is closer to the truth. And one could quibble about the definition of “dateline”, as Samoa moved across it once.) Interesting take from 1999: Erik Naggum: The Long, Painful History of Time http://naggum.no/lugm-time.html http://naggum.no/lugm-time.html
bruce511 5y ago
The root of most date/time problems stems from the fact that we use/have insufficient vocabulary to define what we actually want. For example, "time" can be used as "time of day" or "duration". In my own work we have to measure "from this time, to that time" and yhd result should be duration. [1] We also use the phrase Time when we mean Timestamp (a date /time combination). And we use "local timezone" implicitly almost everywhere, where we should be storing everything as UTC and then displaying as desired. (this would make comparisons trivial.) Daylight savings is an abomination since it means time is not contiguous, and the sooner it goes away the better. This is somewhat solved by using UTC when time-stamping. Overall I prefer storing everything as UTC, then displaying that as preferred by each user (ie as their local time). [1] should be, but is instead stored as a time field for historical design reasons.
shmerl 5y ago
Date without a time signifies a calendar day, you can't compare it to a date with time. As simple as that.
bjourne 5y ago
If I were to design a new programming language then x > y or x == y when x is the float 1.2 and y the integer 1 would throw an exception. Mathematically that is wrong because obviously 1.2 > 1, but in my experience, trying to compare values of different types leads to much pain and many annoying bugs.
andybak 5y ago
I hate to be "that guy" but I think everyone is looking at this wrong. It's not a programming issue, a type casting issue or a CS issue. It's a UI issue. That the point you got the date and the datetime values, there was a human being (either a user, an admin or a programmer) sitting in front of the screen and they were asked a question in some way. The precise way that question was presented affected their intent. It's their intent you are asking about here. So you need to think about what they were asked and how they were asked it. If that was consistent then you can make a reasonable call here. If it's inconsistent at different times and places then the meaning of that date is different and you can't solve this in any reasonable way.
- pg_1234 5y ago
  Often it is first and foremost a type casting issue. Whether you are comparing a date to a datetime or saving a date as a datetime, almost every language turns '2022-01-02' into something like '2022-01-02T00:00:00+0000' i.e. the first second of the day. In practice it is usually safer to convert to '2022-01-02T12:00:00+0000', centering the time in the day and minimizing the chance that timezone related or other errors will move you into a whole new day. The time component is always a lie, but noon is the safest lie.
  - andybak 5y ago
    That seems to be completely counter to the point I was trying to make. It's nothing to do with type casting - you need to consider the intent of the human being who created that data. What did they mean?
wodenokoto 5y ago
I was quick to say that a date equals a datetime at 0 hours and 0 minutes, but after reading and thinkiong about it, I agree that the question is wrong, but a little rephrasing can probably help solve the problem at hand: - Does this datetime equal this date? No, no it doesn't and never will. - Does this datetime fall on this date? Yes, it might. - Is this date, the date of this datetime? Yes, it might be.

132 points by holman 5y ago

Just create a new time zone.

This site finds the midpoint between date/times as well as the difference between them. Also, time units can be added or subtracted from one date/time to get another. All of this is done through the JavaScript Date object which leaves to trace of the original time zone in arriving at the offset in milliseconds since 1970. If doing the difference between dates in days, round the difference to the nearest day to avoid problems with daylight savings time not being in effect for one of them. https://wjporter.com/misc/MidPoint.htm https://wjporter.com/misc/MidPoint.htm

rlhamil 5y ago

How about this: a date, or indeed even a time, is either of the shortest unit used in calculation at some moment (say by convention, the start of the date or time expressed perhaps down to nanoseconds); or it is a range, from the start of the date or time (expressed in terms of the shortest unit used in calculation, unless you want to fiddle with going down to Planck times to allow for future increase in precision) up to but not including the start of the next increment at the stated precision (for a time in seconds with a minimum resolution of nanoseconds, the billion nanoseconds starting at the beginning of the second). So,an hour range starting at a half hour boundary might fall entirely within a day, entirely outside that day, or half in that day and half before or after it. All of that neglects time zones, or assumes they're at most recorded for local convenience and/or historical purposes but converted for calculation into UTC or the like. So, for instants, either they're equal or they're not; but for ranges, they could be equal, or a smaller range entirely within a larger, or partly overlapping, or disjoint. Pick whichever model (instant or range) works best, and be consistent thereafter, and at least the surprises shouldn't be too surprising.

derac 5y ago

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?

kingcharles 5y ago

When you hit problems like these, the easiest solution is often to set fire to your computer and move to Tibet.

phendrenad2 5y ago
What do programmers in Tibet do?
- flobosg 5y ago
  Compute all the possible names of God![1] [1]: https://en.wikipedia.org/wiki/The_Nine_Billion_Names_of_God https://en.wikipedia.org/wiki/The_Nine_Billion_Names_of_God
- dxdm 5y ago
  They have different problems that will make them try to leave Tibet, I assume.

phendrenad2 5y ago

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 5y ago
> 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.
- phendrenad2 5y ago
  No, the article doesn't reveal anything about where this data comes from, other than the vague "user input vs database" which is useless. So their problem is real-world, and has a solution. We're supposed to solve the problem without the benefit of the context that they have, which makes it a contrived academic problem, which was my point.

unleashit 5y ago

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 5y ago
It was a main plot point in the modern movie series. What's the wrath of Kahn?
- unleashit 5y ago
  Khaaaaaaan! Originally in the intro to the second star trek movie: https://en.wikipedia.org/wiki/Kobayashi_Maru https://en.wikipedia.org/wiki/Kobayashi_Maru
  - efitz 5y ago
    "I don't believe in no win situations."
  - Izkata 5y ago
    There was also a whole episode of Star Trek: Prodigy (a kid-oriented series) centered around it a few weeks ago.

axiosgunnar 5y ago

"Is Europe equal to France?"

drewmol 5y ago
True

cema 5y ago

"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.

deleted 5y ago

[deleted]

franky47 5y ago

A list of date/time/calendar quirks and oddities: https://yourcalendricalfallacyis.com/ https://yourcalendricalfallacyis.com/

happytoexplain 5y ago

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 5y ago
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 5y ago

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 5y ago
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.

travisgriggs 5y ago

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

happytoexplain 5y ago
"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 5y ago
  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 5y ago
    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.
    - AprilArcus 5y ago
      Good point! ISO 8601 dates should support timezones. Then a 24-hour "date" could only be in one of standard time or daylight time.
    - Izkata 5y ago
      To really get confusing, let's add in leap seconds. They're added "as needed" and it looks like our most recent one was in 2016. https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second

Waterluvian 5y ago

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 5y ago
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).
- wiredfool 5y ago
  Dates from times are a minefield. I just had a long-standing bug come to the fore because I shifted a view to a materialized view, and embedded deep down in it was a date cast from a time stamp with tome zone. When running as a view, everything was done in the user's time zone (because tits set per connection). When it’s a materialized view, it's he refresher's time zone. This led to some inconsistencies, as the server is properly but inconveniently in UTC.
0x0 5y ago
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 5y ago
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.

bradleybuda 5y ago

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 5y ago
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.
- bobbyi 5y ago
  1:30 AM on whatever date we "fall back" for DST isn't singular in my timezone
  - Laremere 5y ago
    It depends on what you mean by timezones. 1:30am Pacific Time isn't well defined, but 1:30am PST and 1:30am PDT are.
    - PowerBar 5y ago
      Until daylight savings time ends and it's 1:30am twice. Time is hard.
    - danbruc 5y ago
      Those two things are called the time zone - a geographical area that has and had the same time all the time - and the zone time within that time zone which might change from time to time, for example regularly because of daylight saving time or kind somewhat randomly because people change their mind about which time they want to use.

cpeterso 5y ago

What date/time mistakes did UNESCO make that the Ruby documentation is referring to?

tasha0663 5y ago
https://en.wikipedia.org/wiki/World_Book_Day https://en.wikipedia.org/wiki/World_Book_Day

lmilcin 5y ago

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 span of time of unit length. 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, etc. 2021 is a whole year. And in some contexts it makes sense. Way say something happened on 12th of January -- we use Jan, 12th as a label for an entire day that we would otherwise have to denote with two timestamps. But in some contexts what we need is an exact point in time, a timestamp. And here is where a lot of people just don't think / can't recognise a difference between timestamps and labels for a span of time. If you use a wrong model 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. Most software in this case expects two exact timestamps to denote the end of the span of time. And 23:59:59 is just 1 second shy of the actual end of day which means that, even if we are missing an entire second of the day, most of the time everything seems to work fine. Unless you are large bank and you have millions of transactions all over the clock that have to accumulated exactly. Then yes, it makes a lot of difference. 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 5y ago
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.

atsmyles 5y ago

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 5y ago
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)
- Izkata 5y ago
  > Dates without times are... Dates? Aren't we talking about two distinct types here? I assume this is a response to specifically this part: > Dates without times are ranges. If we're talking conceptually about general date/time/datetime comparisons, not pegged to a specific programming language or type system, I agree with it: Dates are a 24-hour range.
  - NateEag 5y ago
    Caveat: The date's range isn't always 24 hours exactly. Leap seconds can make it slightly longer. A daylight savings change makes the date's range 23 or 25 hours, depending on the direction. I would not be surprised if someone popped up with more edge cases I haven't thought of. Dates and times are crazy.
    - PeterisP 5y ago
      If you're treating dates as ranges, then even ignoring the timezones and daylight savings it still doesn't mean that a date implies a range from 00:00 to 24:00 - the mapping is inherently domain-specific and thus depends on the particular interpretation of that date field (thus it's nonsensical to expect a generic answer/comparison rule for "dates" i.e. all dates). For example, in the domain of financial settlement, a future date of 2022-03-03 would imply that the event must happen by the end of business day of 2022-03-03 (and thus an event at 23:00 of 2022-03-03 would be too late and would map to 2022-03-04 instead); and in a similar manner, the appropriate date for any events happening in the middle of a sunday would be either monday or friday depending on what your rules are, as the effective date which you would be using to calculate the number of days between two events (for e.g. interest) in may jurisdictions has to be a business day; so two events timpestamped five minutes apart might need to be treated as if they are on the same day, different days, or in some cases many days apart (e.g. with a combination of Christmas + weekend). Different domains will have different rules; the generic concept of "date" is too vague to define an universal comparison operator and you have to look at the meaning of each specific date field/variable and expect different date fields/variables to need different semantics.

xorcist 5y ago

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.

dejj 5y ago

If you can compare apples with oranges, can you also compare oranges with apples?

alisonkisk 5y ago

gregwtmtno 5y ago

I never understood why programmers have such a hard time with time. There are two and only two pieces of information you need to work with time: seconds past the epoch and location. Everything else is applying legal and social context to the actual data. Here both of those pieces of information are missing on all three questions, so no answers can be given. Any answer to these questions makes assumptions or deductions about those pieces of information.

zabzonk 5y ago
> Everything else is applying legal and social context to the actual data. It's that "Everything else" that programmers have to deal with.
fknorangesite 5y ago
> Everything else is applying legal and social context to the actual data. And then you just draw the rest of the owl.
DaiPlusPlus 5y ago
> There are two and only two pieces of information you need to work with time: seconds past the epoch and location. Everything else is applying legal and social context to the actual data. Date-of-birth? Calendar-quarters? Computer-local time? (No location, only the computer's UTC offset).
shanxS 5y ago
I am with you but you missed a key issue of comparison: granularity. Unix Epoch is by definition at granularity of seconds. How do you compare 2 epochs where one is in seconds while other in milliseconds. We sort of end up in same comparison game.

al_biglan 5y ago

No. No. No. Dates are to Integers as Date+Time is to Floating Point. You (we) -want- to compare them, but you need something akin to a language level specification for these. Otherwise, it is all what you are trying to do/what problem you are solving. Excel (where I suspect 60% or more of this nonsense lives) at least has a clear definition (both are floats, so you can do the comparison). Otherwise, "Down the Wat-hole" for what to expect.

munch117 5y ago

The CS answer: bottom, bottom and bottom. The static typing answer: type error, type error and type error. The dynamic typing answer: exception, exception and exception. The philosophy answer: category error, category error and category error.

lukev 5y ago

I am a little shocked that neither the blog post nor the twitter discussion nor any of the discussion here clearly identifies the missteps of this approach beyond alluding to a "category" or "type" error (which is correct, but not particularly informative.) The issue here is around the semantics of the mathematical operators. It isn't even really about the types to which they apply; there are systems where `=` is well defined on heterogenous types. The reason the answer to all these questions is a clear "no" is that they do not satisfy the core properties of the operators. For example, take equality. Equality in almost all mathematical constructs means that it supports substitution, is symmetric, transitive and reflexive. There are also well defined properties for the concepts of `greater than` and `less than`. So, no, the OP's conclusion "Literally we’re all just making it up" is incorrect. You cannot use the operators `=`, `<`, and `>` between dates and times because they do not satisfy the core properties that define those operators. (I guess you could try to document an alternate definition of equality without the symmetric property in your documentation but... good luck with that not leading to massive confusion.) Where you can just make it up is to define new operators as you actually want them to be. It's not `=`, it's `myDateTime=()` and then you're free to write the definition of that yourself. As long as you're consistent in the UI of how you present it (don't pretend it's vanilla `=` to the user!) you will at least be telling the truth. It may not solve all your problems but at least you won't be feeding any more to the fires of confusion, which you will as long as you keep pretending it's possible to make `=` mean something that's not reflexive.

karpierz 5y ago
I'm not sure I follow. If I define a date MM/DD/YYYY as equal to the time MM/DD/YYYY 00:00 GMT, which of the equality properties am I lacking? Similarly, if I use that definition of equality to convert the date into a time, and then compare it, can't I get '>' and '<'?
- lukev 5y ago
  Well it depends on if you have a type system that distinguishes between "date" types and "instant" types. If you only have instants, then sure, you could do what you're saying, but the context in which the question was poised seems to imply that "dates" and "times" are separate. And if you do have separate "date" and "instant" types, you lose the property of substitution: f(x) = f(y) if x = y for any arbitrary function f.

IgorPartola 5y ago

The questions do not make sense so stop trying to ask them. It’s like asking if 2022-01-01 is an orange. Generally speaking you want context of what the date or datetime is being used for. If you want to know when Christmas takes place you will use a date: it does not take place on 2022-12-25 00:00:00 through 2022-12-25 11:59:59 because this would require a timezone and Christmas takes place at different UTC times around the globe. But you can reasonably say that Christmas takes place on 2022-12-25 and leave it at that to let the implementation of whatever program figure out if it is or is not currently Christmas based on the information it has about time and timezone.

bricemo 5y ago
I think the point is that the nature of software is that these nonsensical questions are “asked” by the code all the time. Data migration, different teams using different formats, user interfaces with imperfect translations, and other scenarios all result in these silly questions popping up. And in the middle sits an engineer who needs to decide how it will work.
- IgorPartola 5y ago
  And my point is that if you don’t understand what the data field represents, don’t make comparisons against it. You must understand the context and then use the data. Otherwise you’ll ask nonsensical questions and get nonsensical answers and then be surprised.
karottenreibe 5y ago
Actually, in Germany Christmas already starts 12/24, so even this seemingly simplistic example is more complex of you support the entire world. Dates are hard.
- skissane 5y ago
  Added to that, in some (but not all) Orthodox majority countries, most notably Russia, Christmas is on 25 December by the old Julian calendar, which is on 7 January by the current Gregorian calendar (which everyone uses, Russia included, for civil/commercial/everyday use). It’s Gregorian date moves forward by one day every century (except for every fourth century, when it doesn’t.) Some of the other Orthodox Churches (such as the Greeks) technically celebrate Christmas, not using the Gregorian calendar, but rather the “Revised Julian” - which happens to be identical to the Gregorian until 2800. I wonder if, come 2800, they’ll remember to move the date of Christmas, or if they’ll think “there’s no point to it, let’s not” (assuming of course that both they, and humanity as a whole, are still around in 2800)

anononymous5 5y ago

ok, my logic. Dates are Intervals of Timestamp (I put uppercase for clarity). A Date is [01/06/2020 0h0m0s..23h59mn59.999s] A Time can be seen as an Interval of Timestamp, albeit of length 0 A Time is [01/06/2020 12:00:00.. 01/06/2020 12:00:00] With these definitions, it's no (interval are different) no [01/06/2020 0h0m0s..1h59mn59.999s] is not included no the interval is fully included

nescioquid 5y ago

Isn't this just a matter of being clear of inclusive or exclusive ranges? Perhaps this is merely a provocation that the general perception of exclusivity or inclusivity rests in the casual programmer's perception (rather than the specification of which I confess ignorance)? Or is the provocation in measuring the contour of a coast? Can it be measured more precisely (surely it can)? In which case is the provocation one of mere precision? Or is the provocation one which asks how many fairies may fit on the head of a pin?

mdoms 5y ago

What is Kobayashi Maru? It's mentioned in the headline and then never again in the article, and never defined.

addaon 5y ago
https://memory-alpha.fandom.com/wiki/Kobayashi_Maru_scenario https://memory-alpha.fandom.com/wiki/Kobayashi_Maru_scenario

ineedasername 5y ago

I deal with this on a regular basis, and my approach is straightforward: I don't compare them. If a have a date on one side and date-time on the other, then I am missing the data necessary to make a comparison. The question seems like a non-sequitur because the implied question is "how do you compare two variable when one of them does not have the data needed for comparison" The only question in circumstance like this is whether or not my requirements allow for-- or can reasonably be modified-- to strip off time and only compare dates. If time is an inherent requirement to the project then the response I give is simple: "Then begin collecting time data."

dudeinjapan 5y ago
This is the correct answer. If you want to ask "Does a given date contain a time?", you find the start and end of that date in the relevant timezone and check if the time value falls in that range.

mdavidn 5y ago

This article doesn’t even delve into time zones. Each UTC timestamp maps to one of two dates, depending on the context of the user or the data. This is important in financial systems. Transactions in Hawaii can legitimately land in a fiscal period that has already closed in New York.

wwilim 5y ago

.NET now has DateOnly. I haven't had the opportunity to use it yet, but I have great hopes for it.

pygy_ 5y ago

Type error. A `date` is a time interval (from midnight to midnight in a given time zone). One could argue that `time` values in computer programs also cover a span, even if it is infinitesimally small for most purposes. The correct operation to compare intervals of varying lengths is not equality, it is either containment or overlap.

hanche 5y ago
One could argue that a date is a region in spacetime. It starts at the dateline, spreads eastward, and ends at the dateline some 48 hours later. (Edit: 50 hours is closer to the truth. And one could quibble about the definition of “dateline”, as Samoa moved across it once.) Interesting take from 1999: Erik Naggum: The Long, Painful History of Time http://naggum.no/lugm-time.html http://naggum.no/lugm-time.html

bruce511 5y ago

The root of most date/time problems stems from the fact that we use/have insufficient vocabulary to define what we actually want. For example, "time" can be used as "time of day" or "duration". In my own work we have to measure "from this time, to that time" and yhd result should be duration. [1] We also use the phrase Time when we mean Timestamp (a date /time combination). And we use "local timezone" implicitly almost everywhere, where we should be storing everything as UTC and then displaying as desired. (this would make comparisons trivial.) Daylight savings is an abomination since it means time is not contiguous, and the sooner it goes away the better. This is somewhat solved by using UTC when time-stamping. Overall I prefer storing everything as UTC, then displaying that as preferred by each user (ie as their local time). [1] should be, but is instead stored as a time field for historical design reasons.

shmerl 5y ago

Date without a time signifies a calendar day, you can't compare it to a date with time. As simple as that.

bjourne 5y ago

If I were to design a new programming language then x > y or x == y when x is the float 1.2 and y the integer 1 would throw an exception. Mathematically that is wrong because obviously 1.2 > 1, but in my experience, trying to compare values of different types leads to much pain and many annoying bugs.

andybak 5y ago

I hate to be "that guy" but I think everyone is looking at this wrong. It's not a programming issue, a type casting issue or a CS issue. It's a UI issue. That the point you got the date and the datetime values, there was a human being (either a user, an admin or a programmer) sitting in front of the screen and they were asked a question in some way. The precise way that question was presented affected their intent. It's their intent you are asking about here. So you need to think about what they were asked and how they were asked it. If that was consistent then you can make a reasonable call here. If it's inconsistent at different times and places then the meaning of that date is different and you can't solve this in any reasonable way.

pg_1234 5y ago
Often it is first and foremost a type casting issue. Whether you are comparing a date to a datetime or saving a date as a datetime, almost every language turns '2022-01-02' into something like '2022-01-02T00:00:00+0000' i.e. the first second of the day. In practice it is usually safer to convert to '2022-01-02T12:00:00+0000', centering the time in the day and minimizing the chance that timezone related or other errors will move you into a whole new day. The time component is always a lie, but noon is the safest lie.
- andybak 5y ago
  That seems to be completely counter to the point I was trying to make. It's nothing to do with type casting - you need to consider the intent of the human being who created that data. What did they mean?

wodenokoto 5y ago

I was quick to say that a date equals a datetime at 0 hours and 0 minutes, but after reading and thinkiong about it, I agree that the question is wrong, but a little rephrasing can probably help solve the problem at hand: - Does this datetime equal this date? No, no it doesn't and never will. - Does this datetime fall on this date? Yes, it might. - Is this date, the date of this datetime? Yes, it might be.