Στον SQL Server, η ημερομηνία 0 είναι  1/1/1900 12:00 πμ. Έχει λογική. Στο .NET η ημερομηνία 0 είναι 1/1/0001 12:00 πμ. Κι αυτό έχει λογική.
Στην VB 6 μαντεύει κανείς ποιό είναι?

30/12/1899 12:00 πμ. Όχι 31/12, 30/12/1899. Έτσι, για ποικιλία. Τώρα, σε VB6, SQL Server και .NET υπάρχει μόνο Date+Time, δεν υπάρχει ένας τύπος ο οποίος να αντιπροσωπεύει μόνο Time. Αναγκαστικά, την ώρα την αποθηκεύουμε σαν ώρα την ημέρα μηδέν.
Και κάποιος πάει και αποθηκεύει ώρα από VB6, χωρίς να έχει υπόψη του αυτή την ασυνέπεια .....

Η συνέχεια στους κινηματογράφους

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Κάτι ανάλογο είχε συζητηθεί και εδώ (αν και με άλλο προσανατολισμό) : http://www.dotnetzone.gr/cs/forums/21608/ShowPost.aspx

Λογικά, αν κάποιο πεδίο στη βάση είναι DateTime με σκοπό την αποθήκευση μόνο ώρας, τότε προφανώς αυτό πρέπει να το ξέρουν όλοι οι εμπλεκόμενοι, είτε γράφουν σε vb.net είτε κάποιοι γράφουν ταυτόχρονα σε vb6. Να ξέρουν δηλαδή ότι η πληροφορία της ημερομηνίας πρέπει να αγνοείται.

Οπότε το σωστό είναι όταν φορτώνει την ημερομηνία/ώρα από την βάση να κάνει:

Dim myDate as date

myDate = TimeSerial(mydatabaseDate.hour, mydatabaseDate.minute, mydatabaseDate.second)

(ok δεν είναι πολύ vb6 valid αυτό αλλά δίνει μια ιδεά)

Αν το κάνει τότε δεν θα έχει πρόβλημα, σωστά;

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Ελπίζω να έπιασα την χωροχρονική ανησυχία σου!

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Την ιστορία πίσω από τις ημερομηνίες στη VB και στο Excel δίνει ο Joel Spolsky στο άρθρο του "My First BillG Review". Για να θυμούνται οι (πολύ) παλιοί και να μαθαίνουν οι (ας πούμε) νεότεροι.

---

Νατάσα Μανουσοπούλου

Την ανησυχία μου δεν την έπιασες. ΔΕΝ ΕΠΡΕΠΕ να συμβαίνει αυτό. Ο λόγος είναι ότι με την παρούσα κατάσταση πρέπει όχι να αγνοώ, αλλά να αποκόπτω το τμήμα της ημέρας, αν δεν θέλω να έχω προβλήματα. Ή, κάθε φορά που μία τιμή ώρας μεταφέρεται από SQL σε VB και το ανάποδο, θα πρέπει να γίνεται η κατάλληλη μετατροπή.

Αν μπορούσα να αγνοήσω την ημέρα θα έγραφα MyDateField + MyTimeField και τελείωσα. Ή θα μπορούσα να κάνω συγκρίσεις με τιμές ώρας που προέρχονται από τη VB: where @currentTime between StartField and EndField.

Τώρα, πρέπει να κάνω μετατροπές και αποκοπές και δεν συμμαζεύεται.

Εδώ που τα λέμε, το πρόβλημα θα ήταν αμελητέο αν ο SQL Server είχε και ξεχωριστούς τύπους για DATE και ΤΙΜΕ, όχι μόνο DATETIME. Αλλά για αυτό το "καλούδι" φαίνεται θα περιμένουμε καιρό ακόμα.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Η ιστορία πάντως περιέχει και μπόλικο μυστήριο. Βρήκα ότι στην Beta 1 του SQL Server 2005 υπήρχαν ξεχωριστοί τύποι Date και Time, αλλά εξαφανίστηκαν στην Beta 2. Μάλλον θα πρέπει να περιμένουμε για την επόμενη έκδοση του SQL Server για να δούμε ξεχωριστούς τύπους date και time

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

pkanavos wrote:

Εδώ που τα λέμε, το πρόβλημα θα ήταν αμελητέο αν ο SQL Server είχε και ξεχωριστούς τύπους για DATE και ΤΙΜΕ, όχι μόνο DATETIME. Αλλά για αυτό το "καλούδι" φαίνεται θα περιμένουμε καιρό ακόμα.

Αυτό είναι το μοναδικό medicine στην υπόθεση... Όλα τα υπόλοιπα προϋποθέτουν τη σύμβαση "ignore date part" ή "ignore time part". Έχουν γραφτεί ένα σωρό άρθρα και έχουν σπαταληθεί ΜBytes και MBytes για προβλήματα του τύπου

Γιατί το query μου δεν φέρνει καμία εγγραφή, αφού του λέω "HireDay=GetDate()" και έχω κάνει σήμερα μερικές εγγραφές!

---

Vir prudens non contra ventum mingit

Προσωπικά θα ήθελα κάποια namespace-based σύνταξη, όπως πχ dateField.Time = otherField.Time .

Η oo λύση της ημερομηνίας και της ώρας όπως αυτή υπάρχει στο .net framework είναι ιδανική

---

Μην αφήνετε τα media να σας "ταΐζουν"!

Αυτό είναι καλό όταν μιλάμε για εφαρμογή, όχι όμως για βάση. Εξάλλου, Όταν θέλεις ένα πεδίο στη βάση να έχει μόνο ώρα ή μόνο ημερομηνία, αυτό είναι που θέλεις να έχει και μόνο. Δεν έχει νόημα να κρατάς στοιχεία ημερομηνίας όταν το μόνο που σε ενδιαφέρει είναι π.χ. ώρες λειτουργίας του χρηματιστηρίου. Διαφορετικά περιπλέκεται ο κώδικας χωρίς λόγο. Π.χ. τί τιμή θα γυρίσει το property .Date ενός πεδίου ώρας? Τί γίνεται αν κάποιος ξεχάσει στον κώδικα να χρησιμοποιήσει την .Time? Που φαίνεται ότι το πεδίο είναι Time και όχι DateTime? Τί θα κάνω index?

Στην ANSI SQL 92 υπάρχουν τύποι Date και Time, ενώ πολλές βάσεις δίνουν τη δυνατότητα να ορίσεις ακρίβεια, π.χ. DateTime Year to Minute, αν δεν θέλεις μεγαλύτερη ακρίβεια από λεπτά, ή Year to Day αν θέλεις ακρίβεια ημερών. Γενικά, ο SQL Server δεν έχει και πολύ πλούσια υποστήριξη για χρόνο (π.χ. σε ποιό timezone είναι το datetime που αποθηκεύσαμε?). Την κάνεις τη δουλειά σου στο τέλος, μόνο που πρέπει να γράψεις κάμποση SQL παραπάνω και να προσέχεις αρκετά.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Αυτό που φοβάμαι από ξεχωριστό τύπο date & time έναντι του datetime είναι κάποια πιθανή έλλειψη συμβατότητας μεταξύ τους λόγω κακής υλοποίησης, εξ' ου και η πρόταση για την namespace oriented λογική.

Προφανώς, η συμπεριφορά όπως την φαντάζομαι, θα αφορούσε ένα πεδίο (datetime), το οποίο εσωτερικά θα ήταν υλοποιημένο ως δύο ξεχωριστά πεδία (nullable?). Το indexing θα μπορούσε να δεχθεί namespace'd τιμές. Όσο για τον κώδικα, δε θα είχε μεγάλες διαφορές, καθώς οι τύποι θα επιστρέφονταν ως DateTime.
Βέβαιως, θα μου πεις ότι αν το casting υλοποιηθεί σωστά, δεν υπάρχει και λόγος για την αύξηση της πολυπλοκότητας με την εισαγωγή νέων εννοιών (όπως τα namespaced πεδίων).

Από την άλλη, η δυνατότητα ορισμού της ακρίβειας μάλλον φαίνεται καλύτερη λύση, αν και πάλι έχει να αντιμετωπίσει τα ίδια προβλήματα (τι γίνεται αν επιλέξω για παράδειγμα ακρίβεια Day to Seconds, και από τον κώδικα ζητήσω το .Year property?). Χμ... Ενδιαφέρον πρόβλημα αρχιτεκτονικής.

---

Μην αφήνετε τα media να σας "ταΐζουν"!

Δεν υπάρχει καν θέμα υλοποίησης. Οι τύποι υπάρχουν ήδη, από το 1992. Τα semantics (ποιός κάνει cast σε ποιόν, ποιός είναι ίσος με ποιόν) είναι επίσης ορισμένα. Είναι απλά έλλειψη του SQL Server. Αντίθετα, η χρήση namespace θέλει αρκετό ψάξιμο και προσοχή. Γιατί δύο πεδία? Μόλις έπαψε να είναι ένας τύπος. Τί θα γίνεται με το άχρηστο πεδίο? Τί θα γίνεται όταν κάποιος ελέγχει για ισότητα με ολόκληρο το πεδίο? Πόσος κώδικας (SQL και εφαρμογή) θα πρέπει να αλλάξει για να χρησιμοποιηθεί το .Time ή το .Date?

Το πρότυπο υπάρχει σχεδόν 15 χρόνια, απλά χρειάζεται να υλοποιηθεί. Μέχρι τότε βέβαια, μπορεί κανείς να φτιάξει ένα UDT σε SQL 2005 που να ξεχωρίζει Data και Time, ή ακόμα και να αποθηκεύσει System.DateTime αντί για SQL DateTime. Μόνο που θα έχει να αντιμετωπίσει όλα τα παραπάνω προβλήματα, και να ξαναγράψει αρκετό κώδικα.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Οπότε περιμένουμε την 2008/9 έκδοση του SQL server!

---

Μην αφήνετε τα media να σας "ταΐζουν"!

... στην καλύτερη των περιπτώσεων !! :D

---

Angel
O:]