![]() |
| Home | Demo | Services | Features | Help | User Forum | Blog | About | |
|
#11
|
|||
|
|||
|
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. |
|
#12
|
||||
|
||||
|
Quote:
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. |
![]() |
| Thread Tools | |
| Display Modes | |
|
|