|
|
Do you have a topic you'd like Thorkil to write about? Click
here to send a request. |
|
Date, Time and Ada (1)
By Thorkil B. Rassmussen
Date and time are often used in application
programming and Ada has the CALENDAR package dedicated to support
the needs. But the concept of local time - including daylight-saving
time (US) and summertime (Europe) - is not addressed in CALENDAR,
giving some challenges especially to native applications that wish
to use dates for display or to comparing file dates.
But first some history about the difficulty of
keeping proper time. The first good attempt at accurate dates was
made by Julius Caesar (or probably his advisors), who set the length
of the year to 365 days with the addition of one leap day every
fourth year. They kept the 12 months with their odd lengths, and we
still use the names of the months from the Romans. The leap day was
defined to be the 6th day before the first day of the
month of the god Mars (March), which ended being February the 24th
and not the 29th as you would expect. But that does not
matter much really.
Though this new calendar appeared to be accurate at
the time, it tended to drift, as the orbit around the Sun takes at
little less than 365.25 days, and the date of the Vernal or Spring
Equinox was coming earlier in the year. In 1582 this shift had grown
to 10 days and Pope Gregor 13th decreed that October the
4th should be followed by October 15th, and
added the 100-year rule, stating that though every 4th
year is a leap year this does not apply to the centuries, unless
those are also divisible by 400. So 1900 was not a leap year, but
2000 was. The Pope being Catholic could only extend his power to the
Catholic countries, and the protestant countries in Northern Europe
waited 118 years, before they followed the lead in 1700. England
waited to change until 1752 and Sweden not until 1753. And let us
not forget Russia that did not switch until 1918, making the October
Revolution in 1917 really taking place in November! The amount of
inter-country relations was rather limited, so every traveler took
his own calendar with him when he traveled, and probably had some
conversion tables for his journey to make sense.
But in general it is a mess when you trade with
territories far away that do not agree what date it is. The
Gregorian Calendar is the world's
de facto standard today, though regions may entertain their own
system, the Chinese, e.g., with their "Year
of the Rat/Horse/Snake . . . ,"
and the Jewish calendar is another example.
So what can be agreed on is that a day consists of
24 hours of 60 minutes of 60 seconds (a weird numbering system we
inherited from the Sumereans that we faithfully stick to, to the
dismay of countless of children who have to learn a system where you
count hours to 24 or more common to 12 twice a day, talk about 'a
quarter past three', 'half hours' and more).
Otherwise all calendars are based on the counting of
these days, or more accurately assigning a day number to each day.
So within a day there are 86400 seconds. With computers, keeping
time by counting seconds since an agreed date became popular - in
Unix systems a 32 bit value counts seconds since Jan 1st
1970. Using the 32 bit value as a signed entity (done - perhaps
inadvertently - by a lot of software) that allows for 24855 days,
before a 32-bit overflow occurs, which will be on January 19th
2038. If Y2K was a big issue, Y2038 will be a bigger one perhaps.
This is why DDC-I licenses never extend beyond this year, when Unix
hosted products are licensed.
The Ada language requires a higher precision in
dates, as they must maintain a range from Jan 1st 1901 to
Dec. 31st 2099, so 32 bits are definitely not enough,
where 64 bits would. But the founding fathers of both Ada83 and
Ada95 decided not to address the local time issue. The concept of
UTC (universal time coordinate) decrees that the time in Greenwich,
England, is the time that all other time is relative to, and is the
same as GMT (Greenwich Mean Time). New York is 6 hours after GMT,
and Copenhagen is 1 hour before. Cleverly the Europeans decided that
you may go both positive and negative from GMT, but the 'date-line',
where dates actually change, is placed in the Pacific Ocean, so all
the Europeans - and Americans as well - could share the same date,
when they were awake. So all countries have - perhaps multiple -
local time zones defining their distance from GMT, typically in the
range -12 to +12 hours. There are also many examples where half hour
distances are used. The dateline is also flexible so that it does
not need to follow a meridian, but may have 'political'
deviations, so a country extending across the 'date-meridian'
would not be forced to have different dates in Eastern and Western
parts. So UTC or GMT is a practical thing to agree on.
Local time may also be burdened by 'daylight-saving
time' or 'summertime',
invented to preserve daylight time, but today more a nuisance than a
help. Summertime may adjust the local time for some part of the year
with as much as two hours. When entered - typically in late March -
you lose an hour and jump from 2:00 in the morning to 3:00 in the
morning, and switching back - typically in late October - you have
two occurrences of the same time, as you at 3:00 jump back to 2:00.
A mess!
Therefore having a timekeeping that is independent
of local time is crucial for avoiding mistakes. This is why file
dates in operating systems usually use the UTC, when recording the
information in the file system, and then convert it to local time,
when displayed in a window. An Ada application executing under an
operating system will receive the UTC time, and package CALENDAR
must decide what time zone it will show. The DACS systems all use
UTC in the program library utilities, so the same library
information will be shown in the same way, regardless of where in
the world the code is executing. But it is very confusing, when it
comes to showing file dates, as the operating system will show local
time, so here Ada-based applications showing file dates must go
beyond the CALENDAR specification to make the necessary conversions,
typical consisting of adding or subtracting a fixed number of
seconds to the UTC date delivered from the operating system calls.
In a later article we will look into some of the
algorithms for local time conversion, as well as for the conversion
of a day number into a proper date.
 |
About the Author
Thorkil Bjørn Rassmussen has worked with DDC-I for over 20
years. He has a Master of Science, Computer Science, from
University of Copenhagen. Thorkil has substantial experience
with all of the DACS tools and is the key individual
involved in all FAA certifications for the DACS product
line. Thorkil lives with his wife Jane and two children
Jonas and Tine, just outside of Copenhagen, Denmark.
|
[
Back to Top ]
By Linda Rising
risingl@acm.org
www.lindarising.org
I have written a couple of articles for the DDC-I on-line
newsletter (Jan 2004, June 2002) on the topic of retrospection. The
essence of the approach is to stop whatever you’re doing and spend
a little time thinking about what has happened so far—on the
current iteration, the release, the entire project. The three
questions to ask at this juncture are: (1) What worked well that
should be continued? (2) What should be done differently? (3) What
still surprises us? Team members get a chance to say what they feel.
My articles describe this practice as a part of the software
development process. My good friend, Norm Kerth, has written an
excellent book on Project Retrospectives [1] and I have written
articles and present a tutorial on tailoring the ritual to meet the
demands of smaller, more agile teams.
Lately, however, I’ve been stumbling across surprising uses of
retrospection. I recently watched the 1989 movie, Glory. The
movie tells the true story of the first black regiment in the Civil
War, the Fifty-fourth Massachusetts Volunteers. An especially moving
scene takes place the night before the regiment will lead an assault
on the Confederate Fort Wagner on July 18, 1863. The men sit around
the campfire and sing gospel songs, and some of them step forward to
say what is on their minds and in their hearts as they realize what
might happen the next day. One soldier in particular, portrayed by
Denzel Washington, seems reluctant to speak, but with encouragement
from the group, he says something like the following:
I’ve never had a family. Don’t remember my father or my
mother, but all of you have become my family. I love the 54th.
Not a dry eye in the place, as this hard-boiled former slave
whose back is covered with scars from many whippings, stands up and
says how he feels.
Having people say what they feel is at the heart of
retrospectives. When people feel they can tell the truth as they see
it, the release of emotion helps them move on to the next project.
What I’m going to share with you in this article is how that
power can be unleashed at a higher level. How the entire company,
not just one team, can experience this.
The story comes from an interesting book, The CEO and the Monk
[2], which shares another true story—about Bob Catell, the CEO of
KeySpan, one of the largest energy companies in the Northeast. The
company has 12,000 employees, one of them is Kenny Moore, who spent
15 years in a monastic community as a priest. These two are the
title characters. Their story is fascinating, and an unusual and
uplifting one in these troubled times. Catell appointed Moore
corporate ombudsman, in an effort to connect the human element with
the business. As Moore notes:
Much to my surprise, the skills of the monastery had a place
in the business world. Employee surveys increasingly confront
executives with three major issues: nobody trusts their
supervisors; employees don’t believe in senior management; and
workers are too stressed out to care. Problems with trust,
belief, and caring. In my monastic days, we referred to this
self-same quandary as a crisis of faith, hope, and charity. I
began to see that I was the only one in the company who had a
core competency for dealing with executives who believed
themselves to be infallible.
There are many adventures along the journey that these two have
traveled together over the past decade. I’ll share the details of
just one.
The company was suffering enormous upheaval as the entire energy
industry was being transformed. To help the 100-year-old gas utility
survive, Moore suggested a radical solution: To get the company to
move forward, there must be a sense of closure on the past before
employees could go through the necessary changes.
There are many examples of companies that have tried to change,
yet failed, largely because they didn’t understand that employees’
first reaction to any change is the feeling of loss. The ending of
the old ways needs to be acknowledged and incorporated into any
corporate change effort.
So Moore suggested a corporate funeral.
"I thought he was crazy," said Catell. "It took me a
little while to grab hold of that. Imagine when I tried to convince
the other officers in the company. They were a little skeptical.
They even thought I was crazy."
Four hundred KeySpan executives were invited to the mock service.
They all paid their respects to the past and looked to the future.
The following is from Catell’s funeral speech:
To begin the journey, we must consider that some of the
changes we are going to experience will have their origins not
in a beginning but in an ending. We all will feel sorrow and
loss in abandoning our old ways of doing business, as well as
when we take up the new skills required to successfully compete
in a deregulated environment. In the process, we will experience
an in-between time—when the old rules no longer apply and the
new rules have yet to be defined. This will make many of us feel
anxious and unsure. However, this in-between time, this
transition period, while ambiguous and unsettling, is necessary
before any progress can be made. We are required to first mourn
the loss of the known and spend time wandering around feeling
lost and alone, the way we would feel if we lost a loved one.
Only then are we ready for a true beginning.
Today is a time to honor and recollect what we were. This is
a memorial to an era that is now concluding, an act of
remembering, embracing, mourning, and moving on. And perhaps
most important, it is an occasion to affirm that you are not
going forward alone. We are in this together and we share all
the anxieties and fears of the unknown. We may grieve
individually, but we will move forward collectively and I am
confident that the best is out there ahead of us.
Moore’s observations:
While some questioned the value of hosting a company funeral,
to me it seemed like the natural thing to do. Rituals and
ceremonies are part of the human experience and predate
organized religion by thousands of years.
When life comes to an end, whether personal or corporate, we
naturally want to mourn that loss, acknowledge our grief, and
seek support from those around us. All this is healthy, for it
heals the soul and helps us move forward productively.
Bob was right when he said things are changing and change
starts not with a beginning but with an ending. Our former way
of conducting business is dead, and attending a funeral is one
timeless way of acknowledging that loss. As a company, if we can’t
say good-bye to the past, we won’t be able to embrace the
present and we’ll miss out on the future.
Employees’ reluctance to see the consequences of
deregulation was the compelling reason I had used to convince
Bob to host this funeral. Workers would continue doing business
as usual, believing that nothing had really changed. From a
corporate perspective, we needed to make our executive business
conversations more public. Only then could we hope to effect
dramatic change. Involving large numbers of employees in these
discussions creates momentum. Ultimately, workers will support
only what they help create.
From Moore’s funeral speech:
Grieving friends, it would be most appropriate at this time
to identify those things that are over for us as we bury our
beloved past. I invite you to share with us those qualities,
behaviors, and business practices that must be buried for us to
successfully move into deregulation.
On a table near the stage, Moore had placed a small funeral urn
and some blank index cards. After a long silence, one accountant
spoke up, "You mean, like the loss of job security?"
"Exactly," said Moore and wrote it on the card and dropped
it reverently into the urn. "What else?" Slowly the
reluctant mourners called out other aspects of the business that
were becoming a thing of the past: guaranteed profits, lifetime
employment, secure growth. One embittered supervisor even said
"the future career of the ‘white male.’" Moore wrote
them all down and place them in the urn without comment.
Moore then said, "Let us now pause for a prayerful moment of
respectful silence for what has gone before us." Taking some
"holy" water, he blessed the urn and explained that while
the past needed to be interred with respect, deregulation was
inviting them into an unknown future.
"Funerals not only acknowledge an ending, they also prepare
us to move forward," Moore explained as he rolled a replica of
the Santa Maria onto the stage. He reminded everyone that they could
expect to feel very much like the early explorers on the high seas:
nervous, scared, and insecure. Pulling a deflated life vest from
beneath the podium, Moore grabbed a young engineer from the front
row and placed it around his neck. "In uncharted waters, we’ll
need to find ways to stay afloat. What might we as a company need to
do to keep buoyant during our transition, as the business rules get
rewritten?"
The audience began to get engaged in this drama of the corporate
journey. They shouted out their answers. "Teamwork."
"Better use of technology." Moore wrote them on cards and
pasted them to the life vest. "Listening to customers can’t
be overlooked." Soon the vest was covered with the future needs
of the company.
Then Moore directed them to blank posters on the walls and
invited them to draw pictures of what they wanted the company’s
future to look like. One group drew a battle scene, with victorious
employees taking the field. Another drew dollar bills floating down
from the heavens with workers getting their fair share of corporate
profits. They spent a few minutes hearing employees explain what
their artistic renderings meant and brought the meeting to a close.
"And then," Catell said, "we used those 400 people
as, I guess, sort of apostles to go out and talk to the rest of the
employees about the need for this change."
The funeral had a strong impact. People still remember it, nearly
10 years later, as a turning point for the company.
If you don’t have time to read the book, check out an on-line
report of the funeral that appeared in Fast Company [3].
This is such a great story about the power of retrospection applied
to lead a company through change. There are other, equally powerful
stories in this book. One of my favorites describes the use of Open
Space to solve computer integration problems. If you’d like to
learn a bit about Open Space and hear this story, drop me a line: risingl@acm.org. I’m off to a conference in Vienna that is run
entirely using Open Space—stay tuned!
References
1. Kerth, N., Project Retrospectives: A Handbook for Team
Reviews, Dorset House Publishing, 2001.
2. Catell, R.B. and K. Moore with G. Rifkin, The CEO and the
Monk: One Company’s Journey to Profit and Purpose, John Wiley
& Sons, Inc. 2004.
3. Tischler, L., "Kenny Moore Held a Funeral and Everyone
Came," Fast Company, February 2004, 30. http://www.fastcompany.com/magazine/79/firstperson.html
 |
About the Author
http://www.lindarising.org
risingl@acm.org
Linda Rising has a Ph.D. from Arizona
State University in the area of object-based design metrics.
Her background includes university teaching as well as work
in industry in telecommunications, avionics, and strategic
weapons systems. She is the author of numerous articles and
has published three books: Design Patterns in
Communications, The Pattern Almanac 2000, and A Patterns
Handbook. She is currently writing a book with Mary Lynn
Manns: Introducing Patterns (or any Innovation) into
Organizations, to appear in September 2004. |
[
Back to Top ]
|
