Dates? Dates are no problem!

Darsithis

This project I'm working on is an ASP.NET 2.0 project inherited from a string of really bad developers. One particular instance takes the cake:

The previous devs clearly didn't know anything about Sql or how to use DATETIME functions in T-SQL queries. So instead of learning, they created a giant table called Calendar. In that table, without any form of indexes, they managed to script the creation of every single day containing the day of week, day of month, day of year, month, year, week of month and so on for a full century. They would then link any queries need to reference date times to this giant table that was agonizingly slow. If a report needed the name of a month, they would pull it from this giant table by querying year, month, and day and pulling out the month name (they'd get the month from the VB code where they at least understood the basics of DateTime.Now).

It's taken me countless hours to remove this ridiculous table and convert all of the queries to avoid it.

Ben L.

Their thought process:

This data contains dates
Dates are such an obscure type of data I'm sure nothing we use has date support
Instead of Googling "ASP.NET 2.0 DATE" I'm just going to program my own date class
Wait, what if I need to store this in a database? Oh dear, I'll need to add that data. I'm pretty sure no database supports dates.
OP punches developer in the face

mott555

That sounds like a standard data warehouse. Except for the lack of indices. It allows non-technical users to easily query data for reports without having to worry about formatting or conversions which can really slow down a report that top management wants right freaking now.

dhromed

@mott555 said:

That sounds like a standard data warehouse. Except for the lack of indices. It allows non-technical users to easily query data for reports without having to worry about formatting or conversions which can really slow down a report that top management wants right freaking now.

And Darsithis just killed it! Whoops!

Darsithis

@mott555 said:

That sounds like a standard data warehouse. Except for the lack of indices. It allows non-technical users to easily query data for reports without having to worry about formatting or conversions which can really slow down a report that top management wants right freaking now.

Perhaps that is useful in a case that you're suggesting but the end-users have no capability in this application to write their own reports or queries. Only pre-made reports are available and only developers and system admins have access to the backend.

DaveK1

@Ben L. said:

thought process

You're too kind.

Fjp

@Darsithis said:

It's taken me countless hours to remove this ridiculous table and convert all of the queries to avoid it.

In that order?

dhromed

@Fjp said:

@Darsithis said:
It's taken me countless hours to remove this ridiculous table and convert all of the queries to avoid it.
In that order?

Crash & Burn is a pretty loud noise, so you know there's still some in there.

mott555

@Darsithis said:

@mott555 said:
That sounds like a standard data warehouse. Except for the lack of indices. It allows non-technical users to easily query data for reports without having to worry about formatting or conversions which can really slow down a report that top management wants right freaking now.

Perhaps that is useful in a case that you're suggesting but the end-users have no capability in this application to write their own reports or queries. Only pre-made reports are available and only developers and system admins have access to the backend.

If it's not a data warehouse then yes it's a WTF. Perhaps a DBA who only understands data warehousing ended up working on this project and didn't realize normal applications call for different database principles.

Darsithis

@Fjp said:

@Darsithis said:
It's taken me countless hours to remove this ridiculous table and convert all of the queries to avoid it.
In that order?

Actually...yes. First I checked dependencies for the table in Sql and corrected those but unfortuantely it's referenced in a lot of visual datasets (ugh) so I removed the table, ran selenium script to run all of the reports, and recorded the ones that failed due to missing that table. From there it's just a matter of fixing each query and then updating the reports.

Still very tedious.

da_Doctah

When my doctor finally identified me as a type-II diabetic, he gave me some preliminary advice on modifying my diet: white rice bad, brown rice good, eat a lot of protein, lay off bagels, etc.

He made it quite clear that in the general category of fruit, dates are very much a problem.

dkf

@mott555 said:

That sounds like a standard data warehouse.

What? I knew they were stupid, but…

dhromed

@da Doctah said:

He made it quite clear that in the general category of fruit, dates are very much a problem.

What did he say about the datas?

Ben L.

@dhromed said:

@da Doctah said:
He made it quite clear that in the general category of fruit, dates are very much a problem.

What did he say about the datas?

Insert joke about cryptographic salts

Ronald

@mott555 said:

@Darsithis said:
@mott555 said:
That sounds like a standard data warehouse. Except for the lack of indices. It allows non-technical users to easily query data for reports without having to worry about formatting or conversions which can really slow down a report that top management wants right freaking now.

Perhaps that is useful in a case that you're suggesting but the end-users have no capability in this application to write their own reports or queries. Only pre-made reports are available and only developers and system admins have access to the backend.
If it's not a data warehouse then yes it's a WTF. Perhaps a DBA who only understands data warehousing ended up working on this project and didn't realize normal applications call for different database principles.

It is common to find a denormalized Time/Date dimension in a relational database if there is a BI app somewhere executing ROLAP queries against live data (e.g.: Tableau). That is not a WTF at all and it is not merely for formatting or conversion for a client; it is a required artifact allowing the ROLAP engine to roll up data quickly.

I don't know if there is or was at some point such BI app in the OP's company but TRWTF is someone making fun of a data structure he clearly has no clue about.

@Ben L. said:

@dhromed said:
@da Doctah said:
He made it quite clear that in the general category of fruit, dates are very much a problem.
What did he say about the datas?
Insert joke about cryptographic salts

Insert joke about anorganic chemistry.

dhromed

@Anonymouse said:

@Ben L. said:
@dhromed said:
@da Doctah said:
He made it quite clear that in the general category of fruit, dates are very much a problem.
What did he say about the datas?
Insert joke about cryptographic salts
Insert joke about anorganic chemistry.

Insert joke about Pringles.

dkf

@dhromed said:

@Anonymouse said:
@Ben L. said:
@dhromed said:
@da Doctah said:
He made it quite clear that in the general category of fruit, dates are very much a problem.
What did he say about the datas?
Insert joke about cryptographic salts
Insert joke about anorganic chemistry.
Insert joke about Pringles.

Insert joke about American Cheese.

DrPepper

@Darsithis said:

@Fjp said:
@Darsithis said:
It's taken me countless hours to remove this ridiculous table and convert all of the queries to avoid it.

In that order?
Actually...yes. First I checked dependencies for the table in Sql and corrected those but unfortuantely it's referenced in a lot of visual datasets (ugh) so I removed the table, ran selenium script to run all of the reports, and recorded the ones that failed due to missing that table. From there it's just a matter of fixing each query and then updating the reports.
Still very tedious.

Plus one to Darsithis for having automated test scripts. Although why you need selenium, where actual unit tests would have sufficed, is a question.

Ronald

@DrPepper said:

@Darsithis said:
@Fjp said:
@Darsithis said:
It's taken me countless hours to remove this ridiculous table and convert all of the queries to avoid it.

In that order?
Actually...yes. First I checked dependencies for the table in Sql and corrected those but unfortuantely it's referenced in a lot of visual datasets (ugh) so I removed the table, ran selenium script to run all of the reports, and recorded the ones that failed due to missing that table. From there it's just a matter of fixing each query and then updating the reports.
Still very tedious.

Plus one to Darsithis for having automated test scripts. Although why you need selenium, where actual unit tests would have sufficed, is a question.

Of course. When one is involved in useless, time-consuming refactoring that brings absolutely nothing to the business (except risk and disruption), one might as well use automation. This will not remove the need for regression tests and unforeseeable amounts of troubleshooting for reports that used to work but that are now mysteriously either failing or inaccurate, but who cares. What matters is that reports use date functions to generate dates dynamically instead of using a list of dates (it's a lot more resilient, who knows when calendars may change!).

I'm sure if they were presented with this Valuable Optimization the higher-ups in that company would be thrilled to see how their IT labor budget is spent.

error

If we believe the OP (and I generally try to give them the benefit of the doubt) there were no indexes on this heavily used table, so it was killing performance. So, removing it had a quantifiable gain (drastically improved response time). The same probably could have been accomplished with some indexes.

Nothing I've heard suggests anything like an OLAP cube. There are situations where a date table isn't WTFy but this doesn't sound like one of those.

One thing I can think of that might be easier with a table is business days. Those aren't necessarily the same from company to company or even from year to year within the same company, so it may well be easier to store holidays in a table.

Ronald

@joe.edwards said:

If we believe the OP (and I generally try to give them the benefit of the doubt) there were no indexes on this heavily used table, so it was killing performance. So, removing it had a quantifiable gain (drastically improved response time). The same probably could have been accomplished with some indexes.

Nothing I've heard suggests anything like an OLAP cube. There are situations where a date table isn't WTFy but this doesn't sound like one of those.

One thing I can think of that might be easier with a table is business days. Those aren't necessarily the same from company to company or even from year to year within the same company, so it may well be easier to store holidays in a table.

Adding indexes or simply creating table partitions would have solved the performance issue without requiring any kind of heavy labor or regression tests. Anyways there is no guarantee that the OP's "solution" will work better, as date functions are non-deterministic and therefore will throw a few wrenches in the query optimizer gears; also those functions are likely to be called for each row if they are used within a SELECT or WHERE clause, which is exponentially worse than a fine-tuned denormalized table. As for OLAP - based on his comments regarding the Time/Date dimension I doubt that the OP even knows what it is. Basically this is a simple case of someone not liking something and fixing what is not broken. And he comes here claiming that he solved a WTF. TRWTF.

As for holidays: in many organization this can be indeed quite a bitch. I've often seen companies using providers like Copp Clark and that's not cheap.

Ben L.

@Ronald said:

date functions are non-deterministic

What

Ronald

@Ben L. said:

@Ronald said:
date functions are non-deterministic

What

Please provide the return value for this call:

SELECT DATEPART(dw,'2000-01-01')

See, there is a dependency on whatever you choose to put as the first day of week. Now, in your organization you may agree with various people that the first day of week is Sunday, but unfortunately from the database engine perspective the value can change at any time based on environment parameters (SET values), which would cause this function to return different results without changing the arguments (i.e.: it's non-deterministic).

Now there are some date functions that are deterministic (datediff, etc) but those are not relevant to this discussion since the Time/Date dimension would not contain their output anyways. What you will find in a Time/Date dimension is typically the stuff that would be returned by non-deterministic date functions, such as date parts.

Does that answer your idiotic "what"?

Ben L.

@Ronald said:

@Ben L. said:
@Ronald said:
date functions are non-deterministic

What

Please provide the return value for this call:
SELECT DATEPART(dw,'2000-01-01')

Saturday. Any more questions?

You said date functions are non-deterministic. I asked for clarification. You replied with a date function. I replied with an answer that will never ever change.

Weekday is an int, by the way.

Ronald

@Ben L. said:

@Ronald said:
@Ben L. said:
@Ronald said:
date functions are non-deterministic

What

Please provide the return value for this call:
SELECT DATEPART(dw,'2000-01-01')
Saturday. Any more questions?
You said date functions are non-deterministic. I asked for clarification. You replied with a date function. I replied with an answer that will never ever change.
Weekday is an int, by the way.

You reply with yet another off-topic Golang link. That's all you do.

Darsithis

@Ronald said:

It is common to find a denormalized Time/Date dimension in a relational database if there is a BI app somewhere executing ROLAP queries against live data (e.g.: Tableau). That is not a WTF at all and it is not merely for formatting or conversion for a client; it is a required artifact allowing the ROLAP engine to roll up data quickly.

I don't know if there is or was at some point such BI app in the OP's company but TRWTF is someone making fun of a data structure he clearly has no clue about.

Oh it's absolutely necessary if you want to get the number of business days in a particular month when calculating attendance or payroll or something for a report. Believe me, I'm no novice to calendar tables. This particular one was used solely to get the name of days (mon/tues/wed) and the name of months (jan/feb and so on), all information easily generated without using a table with a [i]century[/i] of date times in it.

@joe.edwards said:

If we believe the OP (and I generally try to give them the benefit of the doubt) there were no indexes on this heavily used table, so it was killing performance. So, removing it had a quantifiable gain (drastically improved response time). The same probably could have been accomplished with some indexes.

Nothing I've heard suggests anything like an OLAP cube. There are situations where a date table isn't WTFy but this doesn't sound like one of those.

One thing I can think of that might be easier with a table is business days. Those aren't necessarily the same from company to company or even from year to year within the same company, so it may well be easier to store holidays in a table.

Yeah business days would have been useful, definitely.

@Ronald said:

Adding indexes or simply creating table partitions would have solved the performance issue without requiring any kind of heavy labor or regression tests. Anyways there is no guarantee that the OP's "solution" will work better, as date functions are non-deterministic and therefore will throw a few wrenches in the query optimizer gears; also those functions are likely to be called for each row if they are used within a SELECT or WHERE clause, which is exponentially worse than a fine-tuned denormalized table. As for OLAP - based on his comments regarding the Time/Date dimension I doubt that the OP even knows what it is. Basically this is a simple case of someone not liking something and fixing what is not broken. And he comes here claiming that he solved a WTF. TRWTF.

As for holidays: in many organization this can be indeed quite a bitch. I've often seen companies using providers like Copp Clark and that's not cheap.

You're right. Doing so would have corrected most issues. However, I've found that I still have to go back to it. For instance, I came across a report earlier today that was failing to execute in-application due to timeout. I carefully investigated it and found it was taking about an hour to execute a report that shows time card history for someone. When I looked closer I found the result set was mostly duplicate records that were obviously a mistake, showing someone working 5.25 million hours a day, 1,300 times for the same day. What I found when digging deeper is they would cross join the pay periods table to the time cards table (no predicates), then filter after the join for the employee. Beyond having some messed up math anyway the real solve was just querying the time cards table joining to pay periods on employee blah blah and now it returns 1,300 records (the actual number of time cards) in 1 second.

That's why I'm doing this. I actually have to fix every report because the idiots who created this were so fucking stupid I fail at words to explain it.

Ronald

@Darsithis said:

I came across a report earlier today that was failing to execute in-application due to timeout. I carefully investigated it and found it was taking about an hour to execute a report that shows time card history for someone. When I looked closer I found the result set was mostly duplicate records that were obviously a mistake, showing someone working 5.25 million hours a day, 1,300 times for the same day. What I found when digging deeper is they would cross join the pay periods table to the time cards table (no predicates), then filter after the join for the employee. Beyond having some messed up math anyway the real solve was just querying the time cards table joining to pay periods on employee blah blah and now it returns 1,300 records (the actual number of time cards) in 1 second.

That's why I'm doing this. I actually have to fix every report because the idiots who created this were so fucking stupid I fail at words to explain it.

What is weird is that if the "stupid people" left a while ago this means that there has never been a successful execution of that report... but if that report was working (more or less) until you deleted the time period table then you just opened a can of worms. So I guess it's just the timing of things and the fact that you have to fix *every* report that makes me suspicious. Unless those people were fired because they had to write a bunch of reports and delivered none that was working and then you were brought in (which is not how I understand the situation).

This being said, the world is full of people who can't code SQL for shit so odds are that a bunch of them found their way to your company.

Darsithis

@Ronald said:

What is weird is that if the "stupid people" left a while ago this means that there has never been a successful execution of that report... but if that report was working (more or less) until you deleted the time period table then you just opened a can of worms. So I guess it's just the timing of things and the fact that you have to fix *every* report that makes me suspicious. Unless those people were fired because they had to write a bunch of reports and delivered none that was working and then you were brought in (which is not how I understand the situation).
This being said, the world is full of people who can't code SQL for shit so odds are that a bunch of them found their way to your company.

This project was started 8 years ago by a different company that saw a parade of about 18 developers come through it, most of whom were very very poor at their job. The application was never finished and never tested in production with any data at all beyond what was manually entered (and the giant calendar table). It went through cycle after cycle where new developers would break everything and fix it so another one could come along and break it again.

However, once I was put on it I created a set of SSIS packages that moved all their data from their 5 access databases into it, so now it's chock full of delicious data that is exposing the appalling number of flaws in query design.

The report I referred to above did not use the Calendar table; I used it as a reference to explain why even fixing that table wouldn't keep me from having to look through each of the reports anyway, especially these ones as they were done by an overseas dev in India (no hyperbole) who lacked basic English skills and was so bad at HTML that he used non-breaking spaces to center things in table cells after explicitly setting all aligns to left. He wrote these horrible queries that are insanely inefficient and frequently return bad data because he lacked the skill to import it to know that the report was even valid.

I've been hired (I'm the only developer on this project) to get this ASP.NET 2.0 web application into shape as quickly as possible (deliverable next month) and so that's what I'm doing, but I'm sharing all of the fun goodies along the way :). I realize it may seem odd that I would have removed that table but it wasn't being used as an actual calendar table. A case statement or even a join to a simple table containing int/nvarchar for the day/month + name would have sufficed.

Ronald

@Darsithis said:

5 access databases

@Darsithis said:

overseas dev in India

da_Doctah

@dkf said:

@dhromed said:
@Anonymouse said:
@Ben L. said:
@dhromed said:
@da Doctah said:
He made it quite clear that in the general category of fruit, dates are very much a problem.
What did he say about the datas?
Insert joke about cryptographic salts
Insert joke about anorganic chemistry.
Insert joke about Pringles.
Insert joke about American Cheese.

Insert joke where the sun don't shine.

dkf

@Darsithis said:

This project was started 8 years ago by a different company that saw a parade of about 18 developers come through it, most of whom were very very poor at their job. The application was never finished and never tested in production with any data at all beyond what was manually entered (and the giant calendar table). It went through cycle after cycle where new developers would break everything and fix it so another one could come along and break it again.
However, once I was put on it I created a set of SSIS packages that moved all their data from their 5 access databases into it, so now it's chock full of delicious data that is exposing the appalling number of flaws in query design.
The report I referred to above did not use the Calendar table; I used it as a reference to explain why even fixing that table wouldn't keep me from having to look through each of the reports anyway, especially these ones as they were done by an overseas dev in India (no hyperbole) who lacked basic English skills and was so bad at HTML that he used non-breaking spaces to center things in table cells after explicitly setting all aligns to left. He wrote these horrible queries that are insanely inefficient and frequently return bad data because he lacked the skill to import it to know that the report was even valid.
I've been hired (I'm the only developer on this project) to get this ASP.NET 2.0 web application into shape as quickly as possible (deliverable next month) and so that's what I'm doing, but I'm sharing all of the fun goodies along the way :).

You need a hug. And a valium.

antiquarian

@Ronald said:

@Ben L. said:
@Ronald said:
@Ben L. said:
@Ronald said:
date functions are non-deterministic

What

Please provide the return value for this call:
SELECT DATEPART(dw,'2000-01-01')
Saturday. Any more questions?
You said date functions are non-deterministic. I asked for clarification. You replied with a date function. I replied with an answer that will never ever change.
Weekday is an int, by the way.
You reply with yet another off-topic Golang link. That's all you do.

Relevant signature: @Ronald said:

Number of people who think that Ben L. should keep posting Go links:

I would have expected that number to be 1 at most.

error

@PedanticCurmudgeon said:

@Ronald said:
@Ben L. said:
@Ronald said:
@Ben L. said:
@Ronald said:
date functions are non-deterministic

What

Please provide the return value for this call:
SELECT DATEPART(dw,'2000-01-01')
Saturday. Any more questions?
You said date functions are non-deterministic. I asked for clarification. You replied with a date function. I replied with an answer that will never ever change.
Weekday is an int, by the way.
You reply with yet another off-topic Golang link. That's all you do.
Relevant signature: @Ronald said:
Number of people who think that Ben L. should keep posting Go links:

I would have expected that number to be 1 at most.

Ben L. is actually a sockpuppet for Go's malefactors. They've done more irreparable harm to its reputation through his faux evangelism than would have been possible merely by badmouthing it.

Ben L.

@joe.edwards said:

@PedanticCurmudgeon said:
@Ronald said:
@Ben L. said:
@Ronald said:
@Ben L. said:
@Ronald said:
date functions are non-deterministic

What

Please provide the return value for this call:
SELECT DATEPART(dw,'2000-01-01')
Saturday. Any more questions?
You said date functions are non-deterministic. I asked for clarification. You replied with a date function. I replied with an answer that will never ever change.
Weekday is an int, by the way.
You reply with yet another off-topic Golang link. That's all you do.
Relevant signature: @Ronald said:
Number of people who think that Ben L. should keep posting Go links:

I would have expected that number to be 1 at most.
Ben L. is actually a sockpuppet for Go's malefactors. They've done more irreparable harm to its reputation through his faux evangelism than would have been possible merely by badmouthing it.

Actually I just use play.golang.org because it lets me send code to people and lets them run it on a server. If you can point something out that works like that for, say, C#, I'd use that instead just to make you happy.

error

@Ben L. said:

@joe.edwards said:
@PedanticCurmudgeon said:
@Ronald said:
@Ben L. said:
@Ronald said:
@Ben L. said:
@Ronald said:
date functions are non-deterministic

What

Please provide the return value for this call:
SELECT DATEPART(dw,'2000-01-01')
Saturday. Any more questions?
You said date functions are non-deterministic. I asked for clarification. You replied with a date function. I replied with an answer that will never ever change.
Weekday is an int, by the way.
You reply with yet another off-topic Golang link. That's all you do.
Relevant signature: @Ronald said:
Number of people who think that Ben L. should keep posting Go links:

I would have expected that number to be 1 at most.
Ben L. is actually a sockpuppet for Go's malefactors. They've done more irreparable harm to its reputation through his faux evangelism than would have been possible merely by badmouthing it.
Actually I just use play.golang.org because it lets me send code to people and lets them run it on a server. If you can point something out that works like that for, say, C#, I'd use that instead just to make you happy.

Real question: what's to stop people from using play.golang.org as a staging ground for an attack or to send out spam?

Ronald

@PedanticCurmudgeon said:

@Ronald said:
Number of people who think that Ben L. should keep posting Go links:

I would have expected that number to be 1 at most.

One of the ~~modmeddlers~~ beloved guardian angels changed my signature. The original text was: "Number of people who think that Ben L. should Go rape another cat" (it even had a clever Go joke!).

You can never trust that what you read in posts has been submitted as is, there is a new breed of mods on this site that use their privileges to make editorial jokes/statements. I think the forum should be renamed TDMOT (the Daily Ministry of Truth)

Snooder

@Ben L. said:

@Ronald said:
@Ben L. said:
@Ronald said:
date functions are non-deterministic
What

Please provide the return value for this call:
SELECT DATEPART(dw,'2000-01-01')
Saturday. Any more questions?
You said date functions are non-deterministic. I asked for clarification. You replied with a date function. I replied with an answer that will never ever change.
Weekday is an int, by the way.

What he means is that some of the variables involved in calculating the result to some date functions are not included in the function arguments. Which is an interesting artifact of SQL I've never really thought about. It's an unfortunate word choice though, considering that non-deterministic generally means that the result can never be predicted, not that the predictable result simply needs more information that isn't immediately obvious.

error

@Ronald said:

I think the forum should be renamed TDMOT (the Daily Ministry of Truth)

Everybody seems to think the horror of 1984 was the oppression of Big Brother. To me, the really scary thing was the malleable nature of history and language that erode your sense of what is real. You start to question your own memories, and wonder if anyone else notices these things - but you can't talk about it without admitting thoughtcrime. Sanity begins to feel like insanity, and you almost want to believe it all to escape the cognitive dissonance of it all.

Anyway, doubleplusgood book.

Ronald

@Snooder said:

What he means is that some of the variables involved in calculating the result to some date functions are not included in the function arguments. Which is an interesting artifact of SQL I've never really thought about. It's an unfortunate word choice though, considering that non-deterministic generally means that the result can never be predicted, not that the predictable result simply needs more information that isn't immediately obvious.

Deterministic is a SQL keyword in many databases and it indicates that a scalar function will always return the same results if provided with the same parameters. This is an important keyword when building indexes, and since this thread is about using date functions in a database this is not an unfortunate choice of words. Somewhere between 1/3 and 1/2 of date functions in SQL are non-deterministic.

If you use SQL Server, not understanding deterministic vs non-deterministic is not a big concern because the optimizer is safe and if you try to materialize (index) a view that contains non-deterministic functions, the database engine will not let you do it, no matter how hard you insist. But on Oracle if you mistakenly believe that a function is deterministic the database engine will gladly agree and you will get incorrect results once the index is populated. (see this interesting article).

Ronald

@joe.edwards said:

@Ronald said:
I think the forum should be renamed TDMOT (the Daily Ministry of Truth)

Everybody seems to think the horror of 1984 was the oppression of Big Brother. To me, the really scary thing was the malleable nature of history and language that erode your sense of what is real. You start to question your own memories, and wonder if anyone else notices these things - but you can't talk about it without admitting thoughtcrime. Sanity begins to feel like insanity, and you almost want to believe it all to escape the cognitive dissonance of it all.

Anyway, doubleplusgood book.

Did you see this (pro-republican) documentary? They give a pretty good example of how even recent history can be "tweaked": the fact that Sarah Palin never said that she could see Russia from her kitchen (it actually came from SNL). Yet if you go in the street and ask people they will swear she did say that.

Well she's a tool but still.

Ben L.

@joe.edwards said:

@Ben L. said:
@joe.edwards said:
@PedanticCurmudgeon said:
@Ronald said:
@Ben L. said:
@Ronald said:
@Ben L. said:
@Ronald said:
date functions are non-deterministic

What

Please provide the return value for this call:
SELECT DATEPART(dw,'2000-01-01')
Saturday. Any more questions?
You said date functions are non-deterministic. I asked for clarification. You replied with a date function. I replied with an answer that will never ever change.
Weekday is an int, by the way.
You reply with yet another off-topic Golang link. That's all you do.
Relevant signature: @Ronald said:
Number of people who think that Ben L. should keep posting Go links:

I would have expected that number to be 1 at most.
Ben L. is actually a sockpuppet for Go's malefactors. They've done more irreparable harm to its reputation through his faux evangelism than would have been possible merely by badmouthing it.
Actually I just use play.golang.org because it lets me send code to people and lets them run it on a server. If you can point something out that works like that for, say, C#, I'd use that instead just to make you happy.
Real question: what's to stop people from using play.golang.org as a staging ground for an attack or to send out spam?

You mean using stdout? Spamming people on stdout? Or via SMTP?

Hint: the sandbox only allows deterministic programs.

Ronald

@Ben L. said:

package main
import (

"fmt"

"net"

)
func main() {

fmt.Println(net.Dial("tcp", "thedailywtf.com:22"))

}
You mean using stdout? Spamming people on stdout? Or via SMTP?

So Go knows that you planning to use SMTP to spam people when you open a TCP connection on port 22. That's impressive.

Ben L.

@Ronald said:

@Ben L. said:
package main
import (

"fmt"

"net"

)
func main() {

fmt.Println(net.Dial("tcp", "thedailywtf.com:22"))

}
You mean using stdout? Spamming people on stdout? Or via SMTP?
So Go knows that you planning to use SMTP to spam people when you open a TCP connection on port 22. That's impressive.

Whoops! At least it starts with the right letter.

antiquarian

@Ronald said:

You can never trust that what you read in posts has been submitted as is, there is a new breed of mods on this site that use their privileges to make editorial jokes/statements. I think the forum should be renamed TDMOT (the Daily Ministry of Truth)

So you expect what you post here to be edited, but you continue to post anyway? Does that sound a little crazy to anyone else?

Ronald

@PedanticCurmudgeon said:

@Ronald said:
You can never trust that what you read in posts has been submitted as is, there is a new breed of mods on this site that use their privileges to make editorial jokes/statements. I think the forum should be renamed TDMOT (the Daily Ministry of Truth)
So you expect what you post here to be edited, but you continue to post anyway? Does that sound a little crazy to anyone else?

It's called the MdDonalds Drive-Thru syndrome. You know that odds are that you won't get exactly what you ordered and paid for, yet you don't switch to a healthier option.