VM-to-Email Email Timestamp Bug in Version 2.1.12.2489 (Linux)

[DarkKnight]

Hi,

 

I am using Version 2.1.12.2489 (Linux) and I have found a VM-to-Email Email Timestamp Bug.

 

The bug is in the timestamp of the "Sent:" field of the VM-to-Email Email you receive from Pbx-n-Sip, the time is set to GMT (Greenwich Mean Time) and ignores the "General: Timezone:" setting on the Admin System Settings page.

 

The timestamp accessed through the web interface or through the phone itself is correct and unaffected. And, of course, you have your mail program's report on when the email was received, but seeing the email come from 5 hours in the future without annotation of GMT makes you do a double-take. (I'm in Central Time Zone.) I would rather it just show the correct time.

 

I was able to double-check this by using an older version.

 

Is this a known bug? Will this be addressed in the next release?

 

Also, why would this be handled with no problems in earlier versions but somehow become an issue an more "advanced version" -- I thought this fundamental and "old hat" part of things was held down tight already.... or when you make advances you "blow up the code" (including things that WORKED normally) in order to do so?

 

Please let me know what has happened with this one.

 

Thanks!

DK

[Vodia PBX]

The bug is in the timestamp of the "Sent:" field of the VM-to-Email Email you receive from Pbx-n-Sip, the time is set to GMT (Greenwich Mean Time) and ignores the "General: Timezone:" setting on the Admin System Settings page.

 

The timestamp accessed through the web interface or through the phone itself is correct and unaffected. And, of course, you have your mail program's report on when the email was received, but seeing the email come from 5 hours in the future without annotation of GMT makes you do a double-take. (I'm in Central Time Zone.) I would rather it just show the correct time.

 

The email timestamps are always in GMT. That is because the one who receives it might not be in central time. The send time is corrected with an additional argument which looks like -0800 meaning subtract 8 hours. There was a problem with the second argument, but that should be fixed now in the 2.1.12 version.

 

Look for a header like this: Date: Tue, 22 Jul 2008 04:45:55 +0200

 

Also, why would this be handled with no problems in earlier versions but somehow become an issue an more "advanced version" -- I thought this fundamental and "old hat" part of things was held down tight already.... or when you make advances you "blow up the code" (including things that WORKED normally) in order to do so?

 

You make one step forward and count the steps backward... Welcome to the software world !