PawPrint.net Forum

The clock seems to have gotten confused this year about DST. My clock thinks that today, Sunday the 24th, is the last SUnday of October and chnaged my time. Has anyone else noticed this or have a work-around? Obviously I can just wait a week and all will be well, but the 31st being the 5th and last Sunday ( not the 4th Sunday, which might be what the program looks for ) seems to be causing some hassles.
thanks,
Gary

Thanks David,

You were correct that it was only my local clock that was incorrect. I went through the instructions you gave and now it´s working properly.

Try this

Open DST Manager and check the settings for the location.

Save but leave it open.

Open Locations manager and check the settings for the location.

Save but leave it open.

then open the location (the clock) and reselect the location.

Then close the dst manager and locations manager.

This worked for me.

If it is your own location that is going wrong you may need to check your regional settings in control panel.

OK, First Post! I´m having a related problem, though I don´t know where to put it. It´s Monday Nov. 1 and My pawprint clock is still showing an hour off. I did a synch, I shut down and re-launched, I went to DST Manager and the settings all look correct to me. I read the part of the manual again dealing with DST, I went to the web page and got the latest update (6.0.0.0.937)

There must be something obvious I´m missing. I would really appreciate any suggestions you could give.

Chuck

Shaker old son, your efforts with WT & VV ARE appreciated by most of us, likewise, most of us recognise that they are FREEWARE, and can appreciate both the effort behind the programmes and the public spirit in which they have been made available to us.
Take your time, do what you can, when you can - I am having a "grand old time" -NOT! - analyzing and checking the VV formulae and conversions, bit off a big mouthful with THAT one - <grin>
At least  glcoakley was polite, hrlewis jumped to a conclusion impossible to make without the source code, and as far as I am concerned, could make some effort to "correct" and "expand" the Config file(s) and so assist everyone.
May I suggest that as you read through the Forum Posts, you add a quick "Acknowledged - read by admin - added to todo list." Post every now and then - it would make the Forum users a little less likely to post : "It looks like there will not be any help forthcoming on fixing this bug." and also help assure that you are still alive (albiet tired, worn out and frazzled).
Anyway, it´s back to searching for esoteric definitions for me - that bl**dy Cord measure for Timber is a stinker! Almost as much hassles as DST!
Baldy

OK - her´s the deal...

First - WorldTime is certainly NOT the "flagship of PawPrint.net´s product" as has been suggested.

WorldTime is just a project I started when I was consulting around N. America and needed a good timepiece - built at night in hotel rooms/on planes. PawPrint.net is mainly a Web, Photography & Graphic design company, we just make this software available to help out.

I feel it is fairly important that this is clear.

Now, regarding this bug. I have checked the code - FYI WT is NOT looking for the 4th Sunday in a month, as some have suggested, WT´s code is designed to be far more generic then that - building DST from a rules system that I designed to cover the rules from around the world (BTW - I HATE DST with a passion now) It actually counts back from the last day on the month looking for the right day of the week (in the case of "Last x Day of the Month" type rules like this)

I am not sure why this is happening but I will keep trying to find it - that said - I am _very_ busy trying to keep up with work demands from my paying web design customers who have strict deadlines (read: working from 4am until 11pm most days) this in addition to volunteering with the Coast Guard, Duke of Edinburgh´s Award, 3 local community committees, and trying to fit in some time for my family in there somewhere - leave me very restricted in how much time I can devote to WT.

Granted this is an annoying bug - but it will fix itself in a few days and isn´t going to kill anyone in the meantime - I will try to have it fixed so that it doesn´t happen again but I doubt that I´m going to be able to: Find the bug, Fix the bug, Q/A the update, and then re-release the installer - all in what is left of this week.

It looks like there will not be any help forthcoming on fixing this bug. It needs to be addressed in the source code. World Time may be free, but it´s the flagship of PawPrint´s product, and a bug like this advertises programmer carelessness.

The problem seems to have been fixed in WT6, but the database for it is incomplete, and there are other problems with it.

I´d like to point out that this flaw in the code will appear in the last week of October for the next two years (2005, 2006) since there are five Sundays in the month both years. That makes it a major point of trust - or lack thereof.

I am at my wit´s end with this problem. My city (Albany, OR) just doesn´t work. In WT5, the DST rule appears in ´Configuration´ but is flawed. In WT6 the DST line reads "Rule not found." The result is the same - I am stuck with the wrong time in my display.

HELP!

Noticed this last Monday.  I am in Sydney, Australia and we advance 1 hour on the last Sunday in October.  My WT, however, only changed North America and European time.  It kept my Sydney time the same.  If there was something inherently wrong with the application of Last Sunday which also falls on the last day of the month which is also the 5th Sunday, then it should have modified my Sydney time to reflect the required change.  This was with WT5.  I just loaded WT6 and it appears that the time is the correct version, ie NA and EMEA are still in DST.

I was slow in noticing this problem. So I guess it´s not just me, there is actually a bug in the WorldTime program?
Anybody know when it will be fixed?

I just spent an hour troubleshooting this problem, and came to the same conclusion. Instead of looking for the fourth Sunday, the program should have a checksum to account for the 31st day of any month when applicable. When I took programming, this kind of error checking was de rigeur.

The problem needs to be addressed for those of us who prefer WT5 since the same conditions will exist for two more years.