Question

EDIT 2009-Nov-04

OK, donc il a été un peu depuis que je posté cette question. Il me semble que bon nombre des premiers intervenants n'a pas réussi à obtenir vraiment ce que je disais - une réponse commune était une variation sur « Ce que vous dites ne fait pas de sens » - et je l'ai fait un peu à portée de main diagrammes pour illustrer vraiment mon point.

Quand on parle de chiffres, nous parlons généralement des points sur ce que les enfants de l'école primaire LEARN est appelé le numéro de ligne:

La ligne numéro

Maintenant, quand nous apprenons l'arithmétique, nos esprits apprennent à effectuer une transformation très intéressante de ce concept. Evalutating le 1 + 0.5 d'expression, par exemple, si nous avons simplement appliqué notre « numéro pensée de la ligne », nous obligerait à faire en quelque sorte le sens de ceci:

L'ajout de deux points sur la ligne numéro

Il est difficile d'illustrer vraiment, car il est difficile de pensent à ce sujet: « ajoutant » deux points. C'est là beaucoup de répondeurs a lutté avec l'idée d'ajouter des dates (ou simplement rejeté comme absurde), parce qu'ils pensaient des dates points.

Cependant, l'expression 1 + 0.5 fait nous donner un sens, parce que quand nous pensons, nous imaginer vraiment ceci:

Ajouter un numéro (point) et une grandeur (vector)

C'est, nombre (ou point ) 1, plus le vecteur 0,5, ce qui entraîne point 1,5.

Sinon, nous pouvons être imaginions ceci:

L'ajout de deux vecteurs

Cela signifie que le vecteur 1, plus le vecteur 0,5, ce qui entraîne dans le vecteur 1,5.

En d'autres termes, lorsqu'ils traitent avec des chiffres, nous traitons des points et des vecteurs de manière interchangeable. Mais qu'en est-dates? Les dates sont, après tout, essentiellement des chiffres. Si vous ne me croyez pas, comparer cette ligne à la ligne numéro ci-dessus:

Un calendrier

Remarquez la correspondance entre la chronologie et la ligne de numéro? Ce fut mon point: si nous effectuons la transformation ci-dessus avec des chiffres , nous devons être en mesure de le faire avec des dates aussi. Ainsi, l'application de la « pensée chronologique », l'expression 0001-Jan-02 00:00:00 + 0001-Jan-01 12:00:00 ne fait pas beaucoup de sens, comme beaucoup d'intervenants a souligné:

L'ajout de deux points sur une ligne de temps

Mais , si nous faisons la même transformation conceptuelle dans notre tête que nous réalisons chaque fois que nous ajouter ou soustraire des nombres , on peut facilement « repenser » ce qui précède que cette :

Ajout d'un point dans le temps et un vecteur de temps

Il est donc clair, la différence entre un DateTime et un TimeSpan est la même différence qui existe entre un point et un vecteur. Ce que je pense a causé beaucoup de gens à répondre négativement à ma suggestion est qu'il se sent tellement naturel de penser que les dates grandeurs de cette façon. Mais je ne souscris pas à l'argument selon lequel il n'y a pas de point de référence évidente à utiliser comme zéro. Il y a un point de référence évident, et je vais vous donner un indice où il est. Il y a environ 2010 années

Ne vous méprenez pas: Je ne conteste pas le utilité de tracer une fracture conceptuelle entre la notion d'un DateTime et un TimeSpan. Vraiment, ma question tout au long aurait dû être (comme ChrisWsuggéré indirectement), pourquoi ne nous traitons des chiffres et des vecteurs de façon interchangeable lorsqu'ils traitent avec les types numériques réguliers? (Ou: pourquoi nous avons un seul type de int, au lieu de int et intspan?) Il y a une grande différence, et pourtant nous ne pensons jamais vraiment jusqu'à ce que quelque temps à l'école ou au lycée, quand nous commençons la géométrie. Et puis il est traité comme ce nouveau concept mathématique, alors qu'en réalité il est quelque chose que nous avons depuis que nous utilisons appris à ajouter des numéros en comptant avec nos doigts.

En fin de compte, la meilleure réponse est venue de Strilanc, qui a souligné que l'utilisation de DateTime et TimeSpan est vraiment une mise en œuvre d'un espace affines, qui a la propriété commode de ne pas avoir besoin d'un point de référence pour traiter comme origine. Merci donc, Strilanc. Je donne la réponse acceptée à ChrisW, cependant, pour être le premier à mettre en place le concept de vecteurs et des points, ce qui a vraiment arrivé au cœur de la question.

QUESTION ORIGINAL (pour la postérité)

Je ne suis certainement pas de prise de programmation de tous les métiers, mais je sais à la fois PHP et .NET ont une classe de TimeSpan en plus d'une classe DateTime (ou structure .NET), et je devine que c'est le cas dans une variété d'autres langues et des cadres aussi bien (bien que je suis en train d'écrire ce principalement en référence aux structures .NET). Cela peut sembler une question étrange, mais pas TimeSpan redondant?

Si vous pensez que la réponse est évidente ( « ! Un DateTime est un point absolu dans le temps, alors qu'un TimeSpan est une gamme de temps - simple que cela »), considérez ceci: un entier peut être conceptualisée comme soit un valeur absolue (le point sur la ligne numéro) ou à une distance entre valeurs - et on n'a pas besoin de deux types de données distinctes pour ces différentes conceptualisations. Je peux encore écrire 5 + 6 sans aucune ambiguïté quant à ce que je veux dire.

Tant qu'il y est une référence du point zéro cohérent, il me semble qu'il devrait y avoir aucune raison pourquoi on aurait besoin d'un objet TimeSpan pour effectuer des opérations arithmétiques sur les objets DateTime, ou pour obtenir la distance entre eux.

Qu'est-ce que je manque? Pourquoi ne peuvent pas les méthodes uniques et les propriétés de la structure TimeSpan être simplement plié en DateTime?

(Avertissement: Il est pas comme je suis passionné par ce ou quoi que ce soit, je vais bien en utilisant des objets DateTime et TimeSpan comme ils sont destinés à tout le temps que je vais juste poser une question.).

EDIT : D'accord, par exemple simpliste pour illustrer mon point:

Considérons l'équation 10 - 5 = 5. On pourrait lire cela comme "à partir de 10 (valeur), déplacer 5 à gauche (span), et vous vous retrouvez à 5 (valeur)"

Supposons, juste pour rendre les choses faciles, nous louer 1 Janvier 1900 soit le point zéro et on définit des objets TimeSpan en termes de jours seulement.

Alors 10 - 5 = 5 pourrait être compris, en termes de DateTime, que le 11 Janvier 1900-6 Janvier 1900 = 6 Janvier 1900. Ceci est bien, parce que 11 Janvier est juste "10" par notre définition et Janvier 6 est "5" . Le fait que nous visualisons les 10 comme valeur , le premier 5 comme durée , et le dernier 5 comme valeur nouveau est simplement pour notre propre bénéfice conceptuel. Mon point est ceci: que la seule différence réside dans la façon dont vous pensez du nombre, pas ce qu'il est en réalité. C'est la raison pour laquelle nous ne disposent pas des structures séparées pour, par exemple, des valeurs entières et entier travées -. Plaine vieux entier couvre toutes nos bases

Suis-je aucun sens?

Était-ce utile?

La solution

  

considérer ceci: un nombre entier peut être conceptualisée comme étant soit une valeur absolue (le point sur la ligne de nombre) ou une distance entre les valeurs

Par votre logique, il n'est pas TimeSpan qui est unecessary. C'est plutôt DateTime qui est inutile, et pourrait être remplacé par TimeSpan (durée depuis zéro)

Plus il y a le fait que les entiers ont un zéro évident, alors que les dates ne présentent toutefois pas un zéro évident; mais ayant un zéro évident est nécessaire, si vous voulez remplacer « place sur la ligne numérique » avec « distance / span du zéro / origine ».

Edit:

Un point (emplacement sur un plan) ne soit pas identique à un vecteur.

Ils semblent similaires ...

  • Un vecteur (distance du point d'origine) peut représenter un point
  • Un point (par rapport à l'origine) peut représenter un vecteur

... mais la valeur du vecteur qui est nécessaire pour représenter un point donné changera si les changements d'origine.

Il est toujours judicieux d'ajouter deux vecteurs (par rapport); mais, cela n'a aucun sens d'ajouter deux points, sauf en convertissant ces points à des vecteurs, puis en ajoutant les vecteurs.

La somme des deux vecteurs n'est pas affecté par un changement de l'origine, mais la somme de deux points serait affecté par un changement de l'origine si vous les a résumées en les convertissant en vecteurs et en ajoutant les vecteurs (parce que changer l'origine affecterait les valeurs de ces vecteurs).

[Remplacer 'point' avec DateTime et 'vecteur' avec TimeSpan dans l'argument ci-dessus.]

Je pense qu'il ya une réelle différence entre les valeurs absolues et relatives. Je suis ne sais pas pourquoi cette différence n'est pas plus apparente en arithmétique, à savoir pourquoi « nombres » sont utilisés de façon interchangeable pour représenter à la fois les valeurs absolues et relatives.

Autres conseils

Une date ne se comporte pas comme un entier, je ne me souviens pas de la classification de l'algèbre, mais considérez ceci: 

Date + Span = Date
Date - Date = Span  
Date + Date = undefined

Span + Span = Span
Span - Span = Span

Pour une année donnée, 

10 feb + 10 days = 20 feb
20 feb - 20 jan  = 31 days
20 jan + 20 feb  = ???

Ce dernier calcul pourrait être interprété comme significatif si l'on considère une date comme jours-depuis-StartDate. Mais la valeur serait aussi arbitraire que la choiche du StartDate.

(En tant que mathématicien) C'est parce que les opérations arithmétiques sur une « date » ne sont pas fermées ou bien définis, ce qui nécessite la nécessité d'une structure supplémentaire.

Par exemple, le 1 Janvier, 2000-1 Décembre, ...: 1999 =? Nous savons qu'il ya 31 jours entre eux, mais si cela était interprété comme une date, la réponse est Epoch (à savoir zéro) + 31 jours. Ce n'est pas une « date » plus valide.

De même, toutes les opérations arithmétiques sur les entiers ne sont pas bien définis (1/2 n'a pas de réponse dans les entiers .. rendements mathématiques entier zéro, mais 0 * 2 = 0, pas 1 que vous attendez). Cela nécessite la nécessité d'une structure supplémentaire que nous appelons des fractions.

Juste parce que vous peut définir une opération ne signifie pas que vous devrait . Par exemple, l'un de la division des raisons par zéro n'est pas défini est parce que sa définition nécessiterait de sacrifier quelques propriétés très utiles de l'arithmétique (par exemple. Associativité, etc).

La distinction entre un timespan et une date se résume à l'addition. Il est logique d'ajouter deux plages temporelles, mais il n'a pas de sens pour ajouter deux dates sauf si vous avez une date de référence arbitraire . En ne permettant pas plus de dates, vous abstraite date de référence de suite que arbitraire. Je ne sais pas quelle date « 0 » est en .Net, et je ne l'ai jamais besoin de savoir. Est-ce pas beau?

L'ajout de deux dates est presque toujours un bug (sérieusement, essayez de penser à où cela est logique en dehors numérologique). En introduisant plages temporelles (la création d'un Espace affines) vous éliminez toute une classe de bogues.

L'une des raisons est que le fractionnement des types empêche une classe de bugs où vous pensez que vous avez un temps relatif, mais vraiment avoir un temps absolu, et vice versa. Par exemple, plus de deux fois absolus peut être signalé comme une erreur de compilation si les deux types sont séparés.

En outre, IntelliSense (et de découverte pour les débutants) fonctionne mieux lorsque le nombre de membres est smaller-- par des méthodes de séparation entre les deux types, travailler avec chacun devient plus facile.

Question l'inverse: quel serait l'avantage d'affaiblir le système de type à cet égard être

Il est une question de coût par rapport bénéfice et DateTime a le grand avantage de réduire les bugs dus à des calculs de date / heure illogiques en interdisant de telles actions. DateTime existe pour beaucoup les mêmes raisons qu'un système de contrôle de type strict existe en premier lieu: pour faire des erreurs sémantiques dans le code produisent des messages de compilation. les programmeurs qui notify d'erreurs dans leur code.

A l'inverse, il y a le coût d'avoir DateTime. Zilch

Considérons maintenant tomber DateTime. Que gagnerions-nous?

Pour répondre à votre question directement: «n'est pas TimeSpan redondant? » Absolument pas, il réduit les bugs. Il a sans aucun doute, pour moi.

Pensez-y sur le plan conceptuel. Si je vous dis que je suis une fête de 7 jours à partir de maintenant, est « 7 jours » dans cette phrase une date. Pourrais-je dire que mon parti est sur 7 jours? Bien sûr que non, parce que sept jours ne sont pas une date. L'une des idées clés de la programmation orientée objet est de représenter des concepts comme celui-ci dans le système comme types. Il est vrai que nous pourrions représenter tout comme un entier (et en fait, beaucoup de gens ont et font), mais dans la programmation orientée objet, nous avons la notion de types d'articles, et leurs comportements et leurs propriétés, et en ce sens, il fait sens d'avoir un objet qui exprime.

Je pense que vous pourriez faire l'argument opposé à celui DateTime est redondant, et nous ne devrait avoir TimeSpan:)

Sérieusement, toutes les dates ne sont vraiment que des intervalles de temps. Ils sont tous par rapport à un point de départ. Techniquement, il n'y a pas de « année zéro » dans le calendrier chrétien (puisque vous ne pouvez pas vraiment une « année de notre seigneur zeroth »), mais si nous attribuons 00h00 1er janvier 0001 B.C. comme le « point zéro », alors chaque jour qui vient après (ou avant) peut être considéré comme par rapport à cette date. Donc, 00h00 le 19 Septembre 2009 aurait un TimeSpan de 734033 jours.

mathématiquement , DateTime et TimeSpan sont redondants. Mais quand nous écrivons le code, nous essayons de communiquer beaucoup plus que des constructions mathématiques abstraites juste. Toute instance DateTime donnée peut en fait être juste un laps de temps par rapport à un point zéro arbitraire, mais pour la plupart des gens qui lisent votre code, il implique un point particulier sur le calendrier. De même, un TimeSpan implique l'écart entre deux points sur le calendrier.

Dans ce cas, Microsoft a choisi d'être clair plutôt que parcimonieuse. Je ne peux pas dire que je suis en désaccord avec la décision.

Il y a beaucoup de complications dans les dates, par exemple:

  • les années bissextiles
  • secondes bissextiles
  • 1582 modification du calendrier grégorien
  • le fait qu'il n'y a pas une telle chose comme 0 ans
  • différences dans les longueurs des mois

Dates et Traitement des choses différentes comme plages temporelles signifie que ces types de problèmes sont beaucoup moins susceptibles de vous confondre dans la pratique.

son sucre ni plus ni moins ....

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top