[Deploying Sakai] Time zone mismatch on sakai 2.8

Eduardo eduzav at hotmail.com
Thu Dec 1 11:14:34 PST 2011

So, finally may be an oracle/sakai bug???, there will be any sakai note or
document referring to this? 

Don't make sense to fix a GMT time value on code, the idea is to configurate
that behavior throught java parameters, or not?



De: Yzelle, Sonette [mailto:SYzelle at unisa.ac.za] 
Enviado el: Miércoles, 30 de Noviembre de 2011 07:14 a.m.
Para: Matthew Jones; Mike De Simone
CC: production at collab.sakaiproject.org; Eduardo
Asunto: RE: [Deploying Sakai] Time zone mismatch on sakai 2.8


This message (and attachments) is subject to restrictions and a disclaimer.
Please refer to http://www.unisa.ac.za/disclaimer for full details.





We experienced the same problem at Unisa, we also came to the conclusion
that it was Oracle related.

We ended up adding an oracle trigger on insert/update to the sakai_session
and sakai_event tables to add 2 hours to the time to be written away so that
correct time reflects in the tables.





Sonette Yzelle

Portal and Academic Solutions



(012) 429-6259


From: production-bounces at collab.sakaiproject.org
[mailto:production-bounces at collab.sakaiproject.org] On Behalf Of Matthew
Sent: 29 November 2011 06:28 PM
To: Mike De Simone
Cc: production at collab.sakaiproject.org; Eduardo
Subject: Re: [Deploying Sakai] Time zone mismatch on sakai 2.8


Yea, mysql Might do some background processing on the field that Oracle


" <http://dev.mysql.com/doc/refman/5.0/en/datetime.html> TIMESTAMP values
are converted from the current time zone to UTC for storage, and converted
back from UTC to the current time zone for retrieval." -



I think most of the fields are TIMESTAMP WITH TIMEZONE. Super confusing!
Internally MyTime returns all UTC from the Java call


It probably is only a problem if you try to convert after the system is
running, or if you're not familiar with what your system is setup as. This
all sounds super confusing to me, especially the 3 different Oracle version.
This page agrees. ;)


"This data type is very confusing and is to be avoided at all costs." -




On Tue, Nov 29, 2011 at 10:42 AM, Mike De Simone
<michael.desimone at rsmart.com> wrote:

This might be an oracle thing.  I just checked MySQL that's running Sakai
2.8 and events & session times are in the local time rather than GMT.  I do
actively set the timezone as a java system property, so maybe that overrides


e.g., in setenv.sh: JAVA_OPTS="$JAVA_OPTS -Duser.timezone=US/Pacific"


Mike DeSimone
Lead Systems Engineer
rSmart | 602-490-0473

On Tue, Nov 29, 2011 at 08:37, Matthew Jones <jonespm at umich.edu> wrote:

FYI: Sakai Events (and other fields that store the date/time like session)
are stored in GMT. This is because it will be the only time that is ever
constant. It's possibly your data center could relocate, you could have
daylight savings time. GMT never changes with seasons and is always a


Here's some additional information from a post a few years ago.





On Tue, Nov 29, 2011 at 8:46 AM, Eduardo <eduzav at hotmail.com> wrote:

Hy, we’re using Sakai 2.8 on Argentina and we have difference time between
application and database ( three hours mismatch)

Example: when a user logs on application at 17hs the sesión_start field on
table is 20hs



The time zone of Argentina is GMT -3.


All servers (backend and frontends) are synchronizing the hour using ntp
protocol ( <http://www.pool.ntp.org/zone/ar> ar.pool.ntp.org) and the time
zone configurated is GMT+3 (the operating systems are OEL 5.5)


On backend we’re using Oracle 10g release 4 and the time configurated on
instance is OK.


select systimestamp from dual;

29/11/2011 10:32:06,241764 AM -03:00

select current_timestamp from dual;

29/11/2011 10:29:39,827614 AM -03:00


The time on application layout is Ok but the time on oracle table is

The table we’re monitoring is sakai.session and the fields are SESSION_START


On the other hand catalina evironment is: 


CATALINA_OPTS='-server -Xms512m -Xmx3072m -XX:PermSize=128m
-XX:MaxPermSize=512m -XX:NewSize=192m -XX:MaxNewSize=384m
-Djava.awt.headless=true -Dhttp.agent=Sakai
-Dsun.lang.ClassLoader.allowArraySyntax=true -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=false -Duser.language=es


I don’t know how can I fix that error, what do you suggest me?



Eduardo Zavala





production mailing list
production at collab.sakaiproject.org

TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org
with a subject of "unsubscribe"


production mailing list
production at collab.sakaiproject.org

TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org
with a subject of "unsubscribe"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20111201/43a22302/attachment-0001.html 

More information about the production mailing list