|
What's worse, that, or using varchar to store numeric values?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Using VARCHAR to store dates... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Funny enough, this happened to me a couple of weeks ago...must have been a typo in a create table statement from long ago as there is no trace of it now. I was about to pull my hair out when a query with a filter on that 'date' kept giving me 'incorrect' results.??? Sorting wasn't working right either. Luckily, I found it before the client did. 
"Go forth into the source" - Neal Morse
|
|
|
|
|
I found that just two weeks ago!
Imagine my surprise when I entered some text and it crashed on a cast during runtime
What's worse, it was supposed to be a foreign key constraint, but instead the developer used that varchar field to store a smallint in another table and then did an if then else on the smallint to show an actual text
|
|
|
|
|
Why's everyone in this cartoon naked?
|
|
|
|
|
It's the naked truth!
|
|
|
|
|
I hadn't even noticed 
|
|
|
|
|
I'm now working with Julian. (dates stored as int) Obviously it's easy enough to dateadd it, but still a pita. Why someone would choose Julian is beyond me...possibly better query performance?
"Go forth into the source" - Neal Morse
|
|
|
|
|
As in the Julian calendar?
Only Julian I know, but never worked with it because who the hell uses that?
|
|
|
|
|
No, Julian days (abbreviated JD) are based on a fixed origin (noon Jan 1st 4713BC) and counting from there. There are variants like "modified Julian day" (MJD) or "reduced Julian day" (RJD).
There is a whole article on Wikipedia: Julian day - Wikipedia[^]
Mircea
|
|
|
|
|
Mircea Neacsu wrote: (noon Jan 1st 4713BC)
Is that the day when the world was created?
|
|
|
|
|
No, that's Fred's birthday
Seriously, it's a number related to some super large astronomical cycle. Astronomers decided on it a few hundred years ago and, as origin is arbitrary, it stayed like that. For details see:Julian day | Calendar Wiki | Fandom[^]
Mircea
|
|
|
|
|
But didn't all those different astronomical cycles start from zero when the world was created?
|
|
|
|
|
kmoorevs wrote: Why someone would choose Julian is beyond me
Either they're working for the orthodox church, living in the autonomous province of Mount Athos or they just f***ed up.
Possibly all three at the same time.
Wrong is evil and must be defeated. - Jeff Ello
Never stop dreaming - Freddie Kruger
|
|
|
|
|
I apologize if I'm too dense or too nerdy: I don't see anything intrinsically wrong with storing a date as a float.
A 4-byte float value has 3 bytes for mantissa giving 2^24 values that can be correctly represented. That makes almost 17 million days or almost 46000 years. I'd argue that this is decent range for most general purpose applications.
It might be unusual or not keeping with established rules, but is not breaking any (computer) law.
Mircea
|
|
|
|
|
It's simply not a date, and every time you'll have to use it you either need to cast it to a date (performance bottleneck) or you need to know exactly how it's formatted, etc.
It'll also be a matter of time before you get 20201005.00000000003 because it's still floating point arithmetic.
Or perhaps someone will enter 1 or 2020931, who'll say as there are no validations.
I'm now assuming the format of yyyyMMdd, but maybe it'll be days since [some date], like JavaScript and Linux do.
Perhaps people will use a local date, such as 05102020 or 10052020, good luck working with that.
Now let's say the float contains ISO dates in the form of yyyyMMdd and the date is 20201029, now add 7 days, good luck!
All in all, it's a lot of trouble, ambiguity and simply disaster waiting to happen.
If you really need dates that do not fit into any SQL date type, use separate integers for year, month and day, I guess.
|
|
|
|
|
Quote: I'm now assuming the format of yyyyMMdd
I see, you are talking about those dates, with random number of days in the month. Sorry, but in that case the cartoon bubble should have said "Officer, he is using vaguely defined dates!", and yes, that should be a punishable offense.
The only well-defined timestamps are those based on a definition like "the number of <somethings> from <origin>". In case of dates can be "number of days from noon, Jan 1st of 4713BC" (Julian date) or "number of days from midninght, Jan 1st, 1970" (Unix time). Notice that in this case fractional parts have a natural meaning (fractions of a day). For good measure, don't forget to add a meridian so we know exactly what "midnight" means.
Mircea
|
|
|
|
|
Sander Rossel wrote: It'll also be a matter of time before you get 20201005.00000000003 because it's still floating point arithmetic.
Agreed, one has to use decimal.
Wrong is evil and must be defeated. - Jeff Ello
Never stop dreaming - Freddie Kruger
|
|
|
|
|
Quote: Agreed, one has to use decimal.
"Captain's log, stardate 41153.7" Yes, it's decimal 
Seriously speaking you should tell that to all astronomers who use fractional days on a daily basis (sorry, couldn't abstain from the bad pun).
Mircea
|
|
|
|
|
To me, that is a matter of software design philosophy.
A date is not a float, it is a date. So it should not be stored as a float but as a date.
I also shiver at old C, where you coded an infinite loop as "while (1) ...". A logical value is not an integer! And weekdays are Monday, Tuesday, ... Sunday, not integers 0..6 (or 1..7).
Some tools force you to handle data values as being of a different type/class than they are from a semantic point of view. We'll just have to accept that - and wrap it up so that you see as little as possible of that misleading, "wrong" type. (Even in K&R C, you could #define true and false.) If e.g. a database system does not provide a proper Date value, you may be forced to convert it to some acceptable representation when written, and back when read. Your application code should never see that, but treat it as a date type/class.
Couldn't your database write/read wrappers convert dates to/from floats? There is a principal difference between measuring and counting. Would you store NumberOfApples as a float, too? Days are discrete, countable units. They should be treated as countable values, not as measurement values. They should be integers (whether a day count from a given zero, or a multi-field year-month-day value), or, if this is not feasible, as a closed set of string values (e.g. as an ISO 8601 string). But not as a measurement value!
|
|
|
|
|
Quote: Days are discrete, countable units.
Except when they aren't: right now in Sydney it's October 6 while I just started October 5th; the October Revolution started on November 7th and I could keep giving examples of time weirdness. In the words of Dr Who (and he is a Time Lord, so he should know something about that), time is a "big ball of wibbly wobbly... time-y wimey... stuff"[^].
As you said, apples are countable objects and behave like that. Time, for historical and astronomical reasons, was counted in different ways. Sometimes after 0228 you get 0229 and sometimes you get 0301. The fact that after 59 you get 00 (and sometimes after 23 you get to 0) goes back all the way to ancient Babylon.
The only reasonable way to keep track of time is as a measure on a long, continuos axis that has some fixed origin. The actual origin and the unit increment on the axis may depend on your application but that's all it is to it.
Mircea
|
|
|
|
|
Mircea Neacsu wrote: the October Revolution started on November 7th
Because of Julian vs Gregorian Calendar
Wrong is evil and must be defeated. - Jeff Ello
Never stop dreaming - Freddie Kruger
|
|
|
|
|
trønderen wrote: A date is not a float, it is a date. So it should not be stored as a float but as a date.
Actually, DateTime in SQL Server IS stored as a float.
Microsoft has realized how silly this is and has deprecated DateTime and recommend the use of DateTime2 instead.
Wrong is evil and must be defeated. - Jeff Ello
Never stop dreaming - Freddie Kruger
|
|
|
|
|
I assume you know that Excel, Access, and even SQL Server uses floating point numbers to store date and time values.
|
|
|
|
|
Excel and dates is terrible.
Haven't used Access, but I can only assume it's the same.
To say SQL Server saves dates as floating point numbers is a bit simple.
It may do so, but then there's probably a ton of code to make it work like a datetime 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
