skip to Main Content

All UTC times are not necessarily the same

A friend pointed out that all UTC Time is not the same. When he told me, I responded with “What!?! What are you talking about? It’s the same.” “No it’s not” he said. He explained, that yes using UTC will allot you an agreed upon time format but that does not guarantee that both server’s clocks are synchronized.

For example, Sever A calls server B for updates. Both Servers use UTC Time. Server A sends over a timestamp, how do we know that the two servers clocks are synchronized and that the two times match, we don’t. The odds are they are not. How can they be? Absolute time does not exist. It’s all relative. By using a timestamp to retrieve data from another server you are making an assumption that both servers have the same time.

*photo reference

2 minutes on Migrating Data

I had a great talk with my friend Dave today. He’s a Data Scientist. He knows his stuff, for sure.

We talked about a number of things, but one that really stuck out was data migration. He says never to migrate via code, use a tool. You are reinventing the wheel. You are locked into your solution. All the risk is in your court. And the solution is not flexible. With that said. He went on to say the most efficient way to move data is with a primary key and a hash.

The destination side will request all the primary key and row hash. Taking the primary key it will check if the row exists. If it does exist it will compare the hash of the source to the hash of the destination row. If they match then the process is repeated for the next row. If they don’t match, then the primary key is added to a list of rows to request from the source. If the primary key does not exist then the primary key is added to the list of rows to be retrieved from the source. When the row comparison is completed all the rows that are stale or do not exist are requested from the source and persisted to the destination.

Grunt

If you enjoy grunt work you’ll do the above. If you are a developer who enjoys building robust applications you’ll leave the grunt work to the tools.

Chronic Contractor

This developer is always looking for a gig. There is always something better. Chronic Contractors are expensive. Mileage per dollar varies.

They have battled many and because of this they see problems. Something about every gig frustrates them.

Chronic Contractor tend to work in cutting edge technologies and loathe older “inferior” technologies. They have no allegiance, they don’t care if the ship sinks, another is waiting in the docks.

Insecurinator Developer

This developer refuses to find a better job. They have had only one job, and they will not leave it — It’s the only breast they have fed from.

They are treated poorly, paid next to nothing yet they refuse to look for greener pastures. They have an unlimited supply of excuses; they may even in principle agree to find a new job, but they never will.

Mini-Me Developer

This developer follows the King of the Hill Developer like fly’s to shit. This person is the voice of the King of the Hill Developer in their absence. They developer similar mannerisms and will spout similar phrases used by the King of the Hill Developer. They will some day grow up to be a King of the Hill Developer.

Back To Top