Windows Forum

Ask something
Discussion Locked

Why do software developers tie calendars to a system clock

0 helpful
3 replies

by bbaltas

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

We spent several weeks trying to prepare the change in daylight savings time, and we still had problems with our calendars! Can someone give me a reason that a developer would tie a calendar to a system clock? Lets face it 9:00 a.m. is 9:00 a.m. now, three months ago, and it will be 9:00 a.m. in December.

I've been told that it is necessary to use system clocks because calendar appointments can be scheduled accurately across time zones. I think this argument is bunk!

Calendar appointments scheduled across time zones can be done accurately, by the sender including time zone information in the original message, and the recipient checking the time zone when the message is received. If there is a difference, the recipient can apply the correct time automatically in the receiver's calendar. Checking a system clock simply does not make sense.

Developers, am I missing something here?

Bill Baltas

3 replies

by tony hopkinson

is tied to local time.
At design time, (when the developer says put a calender control on the form, it's value is set at that time. So the first thing they do is initialise it to now. That will be the time windows says it is.

Tying your local calendar to the system clock isn't the problem. When scheduling across time zones what should be sent (or received) is the UTC time and the offset from UTC the local machine is at.

It's that bit that didn't happen. So it's an error in the choice of format for the communication.

by wayne m.

I admit I have also had issues with time and date implementations over the years, the choice was made by language developers many years ago. It is rarely cost effective for a developer to create his own custom date implementation, so he reuses the existing one.

The initial need, for various reasons, was to identify the current time and date. The issue was how to change the time from 23:59:59 Day 1 to 00:00:00 Day 2. This required tying time and date together.

There are a lot of implications to tying fixed points in time (times and dates) to running time and perhaps in the future they may become decoupled, but until then for most developments, dates are a lesser importance feature that do not deserve custom effort.

by thechas

All of the time keeping on nearly every computer is tied to the BIOS clock. It is the only real clock on a system, and runs even if the PC is turned off.

Yes, a network can be set up to sync the system clock to a standard clock so that all connected systems have the same time.

So, your system clock is tied to either your BIOS clock, or the Network clock.

Why should a developer use or create another clock or timebase? If they used an alternate clock, they would still have to sync that clock to the system or BIOS clock on a periodic basis.

Next, in your scenario of embedding schedule information into email messages or meeting notices, that bit of information would require a new standard and updates to every mail client software.

With any new required code, comes the risk of security holes. Then, you have corporate networks that strip everything but text from messages to improve security.

Bottom line, it is not laziness on the part of the programmer, but working within established standards and making use of existing system features.

Chas

This discussion is closed to new replies.