Hello.
Date handling in RT have some issues with subj.
Example:
SetToNow - set to local time, but
SetToMidnight - use GMT.
May be this module should be refactored in any way?
Best regards. Ruslan.
Also I’d like to see next function in RT::Date?
{{{ sub SetToLocalMidnight
=head2 SetToLocalMidnight
Sets the date to midnight (at the beginning of the day) local
Returns the unixtime at midnight.
=cut
sub SetToLocalMidnight {
my $self = shift;
use Time::Local;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday) =
localtime($self->Unix);
$self->Unix(timelocal(0,0,0,$mday,$mon,$year,$wday,$yday));
return ($self->Unix);
}
}}}
Date handling in RT have some issues with subj.
Example:
SetToNow - set to local time, but
SetToMidnight - use GMT.
May be this module should be refactored in any way?
Hi Ruslan, I’m glad you brought that up!
I have a corrollary question/issue:
[postgres, if that detail matters – and RT 3.0.6]
If I understand correctly, all the times in the database are GMT,
without timestamp. RT obviously understands this and converts back and
forth as it needs to based on the Timezone, which is part of the local
configuration. All well and good – except:
If my timezone uses daylight savings time (as most do);
Suppose the time of some transaction is 3:00PM clock time, and DST
happens to be in effect;
If I go look at that transaction (via RT) later in the year when DST is
not in effect, does it say 3:00 or something else? (4 or 2, or 2:30 if
you are in some odd part of the world…
Can someone with more understanding of the internals answer this?
(saving me a few hours of code-wading…!)
[This came up because one of my people is doing some fairly complicated
reporting directly out of the database; they want to report on monthly
statistics for billing/financial purposes. The reporting period is
monthly, based on our local time. We concluded that they needed to
factor in DST in the query, because we need the report to say the same
thing if it is run in July or December (on July’s data). Thus, we
subtract either 5 or 6 hours depending on what time of the year the
timestamp refers to. We wished this ajustment wasn’t necessary! The
question above is basically: is RT making this adjustment?]
Thanks!
Jim
Ruslan U. Zakirov wrote:
Date handling in RT have some issues with subj.
Example:
SetToNow - set to local time, but
SetToMidnight - use GMT.
I’d argue that “now” is “now” whatever timezone you work
in, and RT always uses UTC. “Now” in UTC is the same time
as “now” in localtime – it’s “now”. I don’t see any
inconsistency here.
Phil Homewood, Systems Janitor, http://www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - A CyberGuard Company
Phil Homewood wrote:
Ruslan U. Zakirov wrote:
Date handling in RT have some issues with subj.
Example:
SetToNow - set to local time, but
SetToMidnight - use GMT.
I’d argue that “now” is “now” whatever timezone you work
in, and RT always uses UTC. “Now” in UTC is the same time
as “now” in localtime – it’s “now”. I don’t see any
inconsistency here.
Hello, Phil and other.
I didn’t answer because I did think that you are right.
Now, I want return to ‘GMT vs Local’ in RT API.
Attached show scrip show that API is not coherent enought.
Output:
DBIx::SearchBuilder->DoSearch Query: SELECT count(main.id) FROM Tickets
main WHERE ((main.EffectiveId = main.id)) AND ((main.Status !=
‘deleted’)) AND ((main.Type = ‘ticket’)) AND ( ( (main.Created >
‘2004-03-25 14:55’) ) )
Tickets 294
…
DBIx::SearchBuilder->DoSearch Query: SELECT count(main.id) FROM
Transactions main WHERE ((main.Created > ‘2004-03-25 17:55:13’))
Transactions 1964
I think where clauses on Created field isn’t equal for this selects, but
must be the same.
Output:
2004-03-25 18:10:23 (->ISO)
Thu Mar 25 21:10:23 2004 (->AsString)
And what is it? Tricky magic. One sub return local time(that I see on my
hand watches right now) and another return GMT(people somewhere far in
London see on thier hand watches at same time).
Did I request something different??? No. Same, but noted in name of sub
then undocumented feature.
Should I debug SQL queries every time I try to use RT API?
Good luck. Ruslan.
Now, I want return to ‘GMT vs Local’ in RT API.
Attached show scrip show that API is not coherent enought.
Output:
DBIx::SearchBuilder->DoSearch Query: SELECT count(main.id) FROM
Tickets main WHERE ((main.EffectiveId = main.id)) AND ((main.Status
!= ‘deleted’)) AND ((main.Type = ‘ticket’)) AND ( ( (main.Created >
‘2004-03-25 14:55’) ) )
Tickets 294
…
DBIx::SearchBuilder->DoSearch Query: SELECT count(main.id) FROM
Transactions main WHERE ((main.Created > ‘2004-03-25 17:55:13’))
Transactions 1964
I believe this is related to a known bug in 3.0.9. What perl code did
you use to build those queries?
Jesse Vincent wrote:
Now, I want return to ‘GMT vs Local’ in RT API.
Attached show scrip show that API is not coherent enought.
Output:
DBIx::SearchBuilder->DoSearch Query: SELECT count(main.id) FROM
Tickets main WHERE ((main.EffectiveId = main.id)) AND ((main.Status
!= ‘deleted’)) AND ((main.Type = ‘ticket’)) AND ( ( (main.Created >
‘2004-03-25 14:55’) ) )
Tickets 294
…
DBIx::SearchBuilder->DoSearch Query: SELECT count(main.id) FROM
Transactions main WHERE ((main.Created > ‘2004-03-25 17:55:13’))
Transactions 1964
I believe this is related to a known bug in 3.0.9. What perl code did
you use to build those queries?
Sorry, attachment missed.
bug_report.pl (607 Bytes)
Looking at the current code, I don’t think RT should fail in that way
any more (it shouldn’t convert a date into localtime anymore). Can you
tell me if it still fails with 3.0.10rc1?
Jesse Vincent wrote:
Looking at the current code, I don’t think RT should fail in that way
any more (it shouldn’t convert a date into localtime anymore). Can you
tell me if it still fails with 3.0.10rc1?
Since I’ve installed svn+svk I use latest code from trunk. So it’s for
latest version.
I found problem it’s in ticket’s _DateLimit sub. It think that time is
local and convert it to GMT. It’s good for web ui, but not for code.
Best regards. Ruslan.
Jesse Vincent wrote:
Looking at the current code, I don’t think RT should fail in that way
any more (it shouldn’t convert a date into localtime anymore). Can
you tell me if it still fails with 3.0.10rc1?
Since I’ve installed svn+svk I use latest code from trunk. So it’s for
latest version.
I found problem it’s in ticket’s _DateLimit sub. It think that time is
local and convert it to GMT. It’s good for web ui, but not for code.
Ok. it should be handled at the UI layer, not the core. 3.0.10 has
already been tagged, but I can revert it for 3.0.11. Want to bounce me
a patch?
Jesse Vincent wrote:
Jesse Vincent wrote:
Looking at the current code, I don’t think RT should fail in that way
any more (it shouldn’t convert a date into localtime anymore). Can
you tell me if it still fails with 3.0.10rc1?
Since I’ve installed svn+svk I use latest code from trunk. So it’s for
latest version.
I found problem it’s in ticket’s _DateLimit sub. It think that time is
local and convert it to GMT. It’s good for web ui, but not for code.
Ok. it should be handled at the UI layer, not the core. 3.0.10 has
already been tagged, but I can revert it for 3.0.11. Want to bounce me a
patch?
For this no. I’ve got a lot of ideas where to fix RT and allready have
started several sub_projs. I wait for fix and do other stuffs.
Good luck. Ruslan.
Jesse Vincent wrote:
Jesse Vincent wrote:
Looking at the current code, I don’t think RT should fail in that
way any more (it shouldn’t convert a date into localtime anymore).
Can you tell me if it still fails with 3.0.10rc1?
Since I’ve installed svn+svk I use latest code from trunk. So it’s
for latest version.
I found problem it’s in ticket’s _DateLimit sub. It think that time
is local and convert it to GMT. It’s good for web ui, but not for
code.
Ok. it should be handled at the UI layer, not the core. 3.0.10 has
already been tagged, but I can revert it for 3.0.11. Want to bounce
me a patch?
For this no. I’ve got a lot of ideas where to fix RT and allready have
started several sub_projs. I wait for fix and do other stuffs.
Good luck. Ruslan.
Does this change fix it for you?
Index: /local/rt-3.0/lib/RT/Tickets_Overlay.pm
— /local/rt-3.0/lib/RT/Tickets_Overlay.pm (revision 1123)
+++ /local/rt-3.0/lib/RT/Tickets_Overlay.pm (local)
@@ -368,6 +368,7 @@
# FIXME: Replace me with RT::Date( Type => ‘unknown’ …)
my $time = Time::ParseDate::parsedate( $value,
UK => $RT::DateDayBeforeMonth,
-
GMT => 1,
PREFER_PAST => $RT::AmbiguousDayInPast,
PREFER_FUTURE => !($RT::AmbiguousDayInPast),
FUZZY => 1
Jesse Vincent wrote:
Jesse Vincent wrote:
Jesse Vincent wrote:
Looking at the current code, I don’t think RT should fail in that
way any more (it shouldn’t convert a date into localtime anymore).
Can you tell me if it still fails with 3.0.10rc1?
Since I’ve installed svn+svk I use latest code from trunk. So it’s
for latest version.
I found problem it’s in ticket’s _DateLimit sub. It think that time
is local and convert it to GMT. It’s good for web ui, but not for code.
Ok. it should be handled at the UI layer, not the core. 3.0.10 has
already been tagged, but I can revert it for 3.0.11. Want to bounce
me a patch?
For this no. I’ve got a lot of ideas where to fix RT and allready have
started several sub_projs. I wait for fix and do other stuffs.
Good luck. Ruslan.
Does this change fix it for you?
Index: /local/rt-3.0/lib/RT/Tickets_Overlay.pm
— /local/rt-3.0/lib/RT/Tickets_Overlay.pm (revision 1123)
+++ /local/rt-3.0/lib/RT/Tickets_Overlay.pm (local)
@@ -368,6 +368,7 @@
FIXME: Replace me with RT::Date( Type => ‘unknown’ …)
my $time = Time::ParseDate::parsedate( $value,
UK => $RT::DateDayBeforeMonth,
-
GMT => 1,
PREFER_PAST => $RT::AmbiguousDayInPast,
PREFER_FUTURE => !($RT::AmbiguousDayInPast),
FUZZY => 1
Hi.
Yes. Fix API and don’t break Web search. I’ll be happy to see it 3.0.11
Best regards. Ruslan.