StatCounter User Forum  
StatCounter Free web tracker and counter

Go Back   StatCounter User Forum > StatCounter.com > Bugs

Reply
 
Thread Tools Display Modes
  #11  
Old 11-02-2009, 03:52 PM
tosommerfugle tosommerfugle is offline
Junior Member
 
Join Date: Jul 2008
Posts: 12
Default

Well, timezone rollback is not the same all over the world. By now, Europe has mostly standardized on the last sunday of october, meaning that CST was already replaced with CET on october 25. This should make no real difference for this issue.

The email header timestamp does not depend on summer/normal time or rollback. Thus, the notation 01:39:01 +0100 is 100% consistent with UT/UTC (for practial purposes the same as GMT), and always means 00:39:00 UT. The offset basically tells what was done to UT to arrive at the specified value.

You are right that best practices for server management is that they internally always use UT, and then apply the desired timezone when operations (like presentation or midnight detection) depend on local time. Firing off end-of-month scripts for a worldwide application on a fixed time would be a bad idea, unless done 24 hours "too late".

If the script activated shortly after 00:00 UT, my time would be 01:00 CET, meaning that this would not explain the discrepancy, unless the report for some reason does not use current data. However, starting it at 00:00 UT would surely not work well for users having a negative time zone offset.

The timing does not seem to indicate that pre/post rollback would be important. On the other hand, seeing the issue in march and october might be seen as a bit conspicuous. Of course, in case of incorrect handling of rollback, almost anything is possible....

I'm not really depending on the monthly report, and have mainly activated it because it is there, and it was nice to have. I'm downloading the logs (in CSV format) to do my own analysis.

Programming for time-based IT operations does of course require strictly correct calendar handling, which is not trivial due to complex rules for leap years (and leap seconds). Having this in place (and always using UT for server timestamps) end-of-month should only be problematic if very simplistic methods were used, like thinking of a month as 30 days.

Off topic - years ago, I was working on a banking application, with interest calculations beeing complicated by the difference between the real calendar, and an "interest calendar" converting the yearly interest rate to a fixed number for monthly and daily interest rate, based on 360-day years and 12 months of 30 days. As we said - if the customer tried to check interest calculations and arrived at the same amount as the bank, the customer had surely made an error.
Reply With Quote
  #12  
Old 11-03-2009, 12:59 AM
webado's Avatar
webado webado is offline
Moderator
 
Join Date: Apr 2004
Location: Montreal, Quebec, Canada
Posts: 28,150
Default

Quote:
Off topic - years ago, I was working on a banking application, with interest calculations being complicated by the difference between the real calendar, and an "interest calendar" converting the yearly interest rate to a fixed number for monthly and daily interest rate, based on 360-day years and 12 months of 30 days. As we said - if the customer tried to check interest calculations and arrived at the same amount as the bank, the customer had surely made an error.
Yep, that's the "American way" of doing business that involves interest calculations (like yields, mortgages, etc). Always favors the bank

I too used to work in a company that dealt with various financial instruments, doing investment portfolio valuations for clients. As I recall we used to have at least 5 different day-count methods, one of them being the US one, 12-360. They'd get 5-6 extra days of interest in a year, 1 day every 31 day month.

Add to this that while daily interest rate is computed by dividing the annual rate by 360 days yet it was charged compounded.... you can imagine the huge profits.

Oh yeah, capitalism at its best.

I did challenge a bank once when they gave me what they computed for our monthly mortgage. No matter how I was calculating on my end I could not come up with the same amount, the bank's was always higher.

I sat down with the bank rep and showed all my computations using a scientific calculator (not a financial one) from A to Z, and even using a textbook for financial calculations to show the formulae and assumptions I was using. She very sheepishly admitted she was clueless how to compute that, she used tables the bank had prepared which give the payment per $1000 of loan, based on set interest rates and amortisation schedules.

Fishy... This thing went all the way to the top and in the end they admitted having made a programming blunder. How many clients got robbed that way?

Funny, always in their favor ...
__________________
Christina
>>Forum Moderator<<

Please do not PM me for support. The forum is here for that.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 04:29 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.