SnowConvert
The best available tools to perform code migrations from a source database or Spark application to Snowflake.

Oracle
Spark Scala
Spark Python
SQL Server
Teradata

Data Solutions
The premier productivity workbench designed and optimized for teams using Snowflake.

Translation with SnowConvert
Edit, Debug & Deploy
Automated Test Case Generation
Metadata Analysis
Source Code Management

Get Started
There are countless ways to take advantage of BlackDiamond Studio and SnowConvert.

Migration and Other Snowflake Services
Get Up and Running with Snowpark
Using the SnowConvert Trial
Build a Cross-Platform Object Inventory

Monetize Your Data

We Are GAP Mobilize
Free Assessment Tool

Only 330 more days before your leap year bug blows up your system

by John Browne, on Feb 4, 2016 9:41:55 AM

Ok, 2016 is a leap year which means February has an extra day, right? But did you know that there could be another leap year bug waiting to happen on December 31? 

Why? Because sometimes we hard code a year as 365 days, when this year is actually 366 days long. And that means you can blow up on New Year's Eve, long after you've forgotten about Feb. 29 and are into your second bottle of bubbly.

new-years-eve-951749_960_720.jpg

To make things even more interesting, if your application or even your database server is hosted in the cloud, what time zone is it in? When does Feb. 29 or Dec. 31 actually happen? If the clock on your host is running UTC, midnight comes at 4pm Pacific time (when I would see it). 

You can read a lot more about famous leap year bugs in the past and things to check for in this interesting blog post from Microsoft. Like so much of what we have to deal with, something seemingly simple is nuanced with complexity. 

If your legacy apps are struggling to deal with more than just leap year correctness, give us a call. Legacy is all we do.

 

Topics:Extras

Comments

Subscribe to Mobilize.Net Blog

More...

More...
FREE CODE ASSESSMENT TOOL