The Y2038 Problem

The Y2038 problem is similar to the Y2K problem. We’re exactly in between both about now. Both are 18 years away, in either direction. While Y2K is over and was obvious to everyone, Y2038 is not.

The issue here relates to a representation of date and time in Unix systems, and is therefore sometimes referred to as Unix Y2K. The root is the convention to store date and time information as 32bit unsigned integer in such systems. This means, possible values are limited. Time-differences in seconds, starting from 01.Jan 1970 cannot span beyond 03:14:07 UTC on 19 January 2038.

The Y2038 Problem
Calendar

The Y2038 problem will make all calculations beyond this date impossible, until migrated to another representation. At the time being, this seems far away. However, the problem casts its shadows already. Industries, in particular financial markets, often rely on long term forecasts.

Governance issued treasury bonds come with with the longest maturity. Often twenty years, sometimes thirty years. Calculations for complex, long running financing models easily try to estimate returns 20 years and beyond into the future. This is already beyond the problematic date that Y2038 brings. The code to run these calculations is typically complex and stable. Sometimes, it is as old as from 1970. Back then, this date-representation Unix engineers introduced this approach. 32bit covered a long period. John Femellia has a thread, over at Twitter, telling a story about the upcoming issues today.

eMail. Still.

Year 2015. Still eMail is the predominant means of communication. Everybody hates it, most companies make an effort to ban it. Atos wanted to go email free, Telekom shuts off their servers, Daimler even deletes email for people on vacation. Even I receive emails, saying “I need this, but I cannot answer”, quoting the “email free day policy”. Despite all effort, nobody succeeds.

Why? Unclear. While I think email should be banned myself, I have difficulties offering a better option. But I develop a feeling for why this is happening. This morning somebody mentioned he’ll be posting into a slack.com channel. That company claims to simplify communication, make teamwork less painful and busy, all searchable. As if nobody else tried that. And even if slack.com does a good job in what they aim for, they are just another solution.

In my personal, active use are trello.com, Pocket, Salesforce chatter. While my company introduces a community, colleagues swear on private Facebook groups or WhatsApp for simplified communication. Not to mention the tools customers and businesspartners are using. Popular among these are Jive, Atlassian Jira, SAP Jam, but not limited, I’ve seen self hosted communities, bug trackers and ticketing tools.

It’s difficult to keep track of all these tools. But they all send notifications through email.

Which tool do you use to communicate?

Wie man richtig Produktiv ist.

Den meisten wird das alles bekannt vorkommen.

 

Und genau die gleichen werden alles leugnen, was einer anständigen Produktivität so im Weg steht:


 

 

via How to Destroy Your Productivity & Sales Effectiveness [Infographic] – B2B Marketing.

Warum Ingenieure Unternehmen führen sollten

Der Master of Business Adminstration (MBA) hat in den letzten beiden Jahrzehnten bei den Personalentscheidern der großen Konzerne ohne Zweifel zu einem Hoch-anerkannten Titel entwickelt. Immerhin hat die Ausbildung den Anspruch, alle Themen die zur Unternehmensführung wichtig sind, abzudecken. Continue reading “Warum Ingenieure Unternehmen führen sollten”