this post was submitted on 07 Jun 2023
27 points (100.0% liked)

Programming

3347 readers
1 users here now

All things programming and coding related. Subcommunity of Technology.


This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 1 year ago
MODERATORS
 

The primary application at my job was...not well written. Originally .NET Framework 3.5 with a strange collection of approaches to MVC. SQL Server for data. I claimed it look like something written by CS students fresh out of college on their first job. Turned out I was close...it was written by 3rd-year CS interns. We've fixed and improved a ton (including migrating to .NET 6 earlier this year).

One of the ongoing issues was the use of SMALLDATETIME and DATE fields for everything. We've been gradually migrating these to DATETIME2 or DATETIMEOFFSET (we don't have future dates) as UTC. Because 95% of our usage had been CST/EST, we've typically set the time component to 17 hours to get a reasonable noonish time in those zones when we don't have a better time of day.

Had another round of these today and thought it was going well. Finally got it running and everything was +1 day from where it should be. Spent an hour trying to figure out the issue.

Converting for display incorrectly? No. Serializer not doing what was expected? No. Configured time zone got messed up? No. Brought in our DBA to help me figure it out.

I had added 17 days twice.

Side note: I wish everybody was on UTC time and time zones would forever disappear into the ether.

TLDR; Migrated time wrong because I'm stupid.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 3 points 1 year ago

Because it originally didn't account for time zones at all....it was very "everybody is in Virginia". The day was even wrong for many countries. When a training program shifted to include other countries it suddenly mattered. And it correlated to other data that did have times.