**
we're using Australian Time Zone...
"Watson, Matthew (Melbourne)" <[EMAIL PROTECTED]> wrote:
** Thad,
Yep we raised the same issue a while back, got the old "function as design" response from Support. We'd be happy using Date Only fields if the widget in the UT wasn't so horrible. Our users want a calendar, not three drop down lists and a "BC" checkbox.
Matt
**
Indeed, it sounds like your issue lies with the fact that ARS stores time in the database as GMT, but then displays it at the client in the local timezone.
However, one oddity to be aware of is that if you have a date/time field that you are displaying as date only, ARS could actually lose a day every time
someone in a different timezone updates the record (whether or not the value in the datetime field was changed by the user). This happens because the user tool resets the time portion of the field back to midnight when it's displayed as "date only". Take this chain of events for example:
- An East coast user (Ethan) sets the field to 8/14/2006. ARS stores it as the GMT equivalent of 8/14/2006 12:00:00 AM EST.
- A West coast user (Wesley) displays the ticket. The user tool shows the field as 8/13/2006 (with a hidden time component of 9:00 PM).
- Wesley then updates the ticket (not necessarily the datetime field in question). ARS saves the datetime value as the GMT equivalent of 8/13/2006 12:00:00 AM PST.
*** We've just lost a day. ***
- When Ethan opens the ticket he'll see the date as 8/13/2006. If he updates something then its saved as the GMT equivalent of 8/13/2006 12:00:00 AM EST.
- Then Wesley opens the ticket again. He'll see 8/12/2006 as the date. If he changes something, then we've lost two days.
And so on...
I first heard of this issue on the list (from the folks at Amazon), but have seen it happen as late as version 6.3. If anyone wants to test that on 7, I'd be interested to hear if its still an issue. When I brought it to Remedy's attention, they said it "would require a complete redesign of the user tool, which won't happen." Bravo, Support.
Anyway, just thought I'd mention it.
Thad
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry
"Eric Cleereman (IT)" <[EMAIL PROTECTED]>
Sent by: "Action Request System discussion list(ARSList)" <[email protected]> |
|
**
Hi ahaha hehehe,
We've run into the similar issues, except that we gain an hour, rather than losing one. This comes from the timestamps being stored in Remedy in Epoch time. The epoch is relative to Midnight of 1/1/1970 GMT.
I don't know what time zone you are in, but by what you are describing, I'd guess you are located in the southern hemisphere.
I'll describe what I've seen from my time zones, which are Eastern Standard Time (GMT -5:00) and Eastern Daylight Time (GMT -4:00).
In my case, when a date is recorded in the system at midnight of April 1st, our time zone was EST. This would have been stored in the database as an integer containing the number of seconds between Midnight of 1/1/1970 GMT and 5:00 AM of April 1st GMT.
Since that point, my time zone zone has switched to EDT. So looking at the same timestamp now, I would now see that it was 1:00 AM of April 1st, which still be 5:00 AM of April 1st GMT. The difference comes from the time zone I am in when I observe Daylight Savings being only 4 hours behind GMT instead of 5 hours behind.
Another way of looking
at it is: If you described the current time as Midnight, someone from a time zone 1 hour behind you would describe the same moment of time as 11:00 PM the preceding date, while someone an hour ahead of your time zone would describe it as 1:00 AM on the same date as you. All three of you would be correct in your descriptions.
Remedy is presenting the time accurately, given your time zone. If what you are looking to do is have Remedy present the time in the time zone and time it was recorded in, you may do so by recording the timestamp to a character field at that point. Note that while this may seem more intuitive, you will actually lose some precision by doing this, so you may also consider just mirroring it to the character field, rather than eliminating the date time field altogether.
Eric
Cleereman
-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED]On Behalf Of ahaha hehehe
Sent: Monday, August 14, 2006 1:09 AM
To: [email protected]
Subject: date/time issue - daylight saving
**
Hi Guys,
We've got some issues where "occasionally" the date decides to change
itself on certain records.
I'm still trying to trap the exact cause, but it's something like this:
We have a rent record which records your rent due with a from date and
to date (when this rate's applicable)
Every now and again, we get this happening:
Rent From was 1/4/05.
Record is updated (NOT
the date however)
Now date is 31/3/05 (looking closer, it's stored as 31/3/05 11:00pm)
We got lots of this when Daylight saving is in effect.
Please advise.
Thanks!
How low will we go? Check out Yahoo! MessengerÂ’s low PC-to-Phone call rates. __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ ==============================================================================
IMPORTANT NOTICE: This communication,
including any attachment, contains information that may be confidential or privileged, and is intended solely for the entity or individual to whom it is addressed. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message is strictly prohibited. Nothing in this email, including any attachment, is intended to be a legally binding signature.
==============================================================================
__20060125_______________________This posting was submitted with HTML in it___
**********************************************************************
The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you have received this
communication in error, please notify us immediately by return e-mail with the subject heading "Received in error" or telephone +61 2 93357000, then delete the email and destroy any copies of it. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing KPMG client engagement letter. Opinions, conclusions and other information in this e-mail and any attachments that do not relate to the official business of the firm are neither given nor endorsed by it.
KPMG cannot guarantee that e-mail communications are secure or error-free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses.
KPMG, an Australian partnership, is part of the KPMG International network. KPMG
International is a Swiss cooperative that serves as a coordinating entity for a network of independent firms operating under the KPMG name. KPMG International provides no services to clients. Each member firm of KPMG International is a legally distinct and separate entity and each describes itself as such.
Liability limited by a scheme approved under Professional Standards Legislation.
This footnote also confirms that this e-mail message has been swept by MIMEsweeper for the presence of computer viruses. See www.mimesweeper.com for more information.
**********************************************************************
__20060125_______________________This posting was submitted with HTML in it___
Stay in the know. Pulse on the new Yahoo.com.
Check it out.
__20060125_______________________This posting was submitted with HTML in it___
