You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Kevin Meyer - KMZ <ke...@kmz.co.za> on 2011/03/14 17:10:54 UTC
Should timezone information be explicitly set (to UTC) in date/datetime/time values?
Hi guys,
My old bug-bear is back!!
I am experiencing some grief because the Isis applib Date, DateTime
and java.sql.Date (and their value semantic providers) explicitly use an
internal timezone of UTC.
This impact on datastores or anyone creating a date directly.
I've raised this before (a few years ago, if memory serve), but never
reached a resolution..
If the timezone is set to UTC, then all dates (and date times) seem to
be interpreted as in this time zone. This causes problems for me, with
my national (constant) GMT+2 offset, and anyone else not on GMT.
One impact is that if I create a java.sql.Date, I must explicitly create it
via a Calender with a UTC time zone. Simply creating a java.sql.date
using "java.sql.date.valueOf("2010-03-05")" returns a value that does
not compare with applib's Date.
Another impact: Relative comparisons don't work!
A simple proof (please check my logic): If I create an applib Date:
Date applibDate = new Date(2010, 3, 5);
and a DateTime:
DateTime dateTime = new DateTime(2010, 3, 5, 1, 23);
Then the comparison:
dateTime.dateValue().after(date.dateValue())
Fails, because I am at GMT+2!
However, If I change the DateTime to 02h23, then it passes!
This occurs because, deeper down, the Date value is stored (for me)
as: 2010-03-05, 02h00
I can get partial happiness with java.sql.Date if I remove the explicit
setting of the time zone to UTC in the appropriate value semantic
provider (JavaSqlDateValueSemanticsProvider), but then the xml
object store breaks!
By success, I mean that a new java.sql.Date of 3rd March has a cdate
of "2010-03-05 0h00".
People living in GMT will not be affected (until daylight savings time?)
Symptomatically, this should mean that anyone with a timezone west
of GMTcreating a applib date (or maybe just java.sql.date) should get
a date of the previous day!
In both the SQL and the XML object stores, dates are not stored with
an explicit time zone (meaning, 2010-01-01 is 2010-01-01, whether
you're in Japan or Hawaii), so you can't safely assume one?!?
If you're writing an application that manages meetings (for example)
and the participants span multiple time-zones, then I think you need to
handle time zones specially carefully, and in your application/domain
code?
If you don't particularly care about comparing times that are (explicitly)
in different time zones, Date, DateTime and java.sql.Date should just
work!
Comments anyone? Should Isis internal Dates (and DateTimes, etc)
explicitly be based on a timezone set to UTC?
Kevin
Re: Should timezone information be explicitly set (to UTC) in date/datetime/time values?
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
On 15 Mar 2011 at 15:56, Alexander Krasnukhin wrote:
> > a) *two* timezone conversions need to be covered:
> > datastore <-> system <-> UI
> > In general, the datastore and system will have the same timezone, but
> > this must not be *assumed* to be the case.
>
> Yep, it must be defined somewhere explicitly.
Forgive me for being pedantic, but I want to repeat: You're
recommending that *two* timezone conversions been to be
considered: when (1) temporal data passes between "the system" and
"the datastore" (since the datastore has an internal, configurable,
timezone), and (2) when temporal data passes between "the system"
and "the user interface".
Typically, "the datastore" and "the system" will have the same
timezone. Generally, "the user interface" will also have the same time
zone. In exceptions, each of the above could have different timezones.
In this case, I would have to assume that it is intended that any
*programmatically* create date/datetime is expected to use the "the
system" timezone? Or should it use the logged-in user user time
zone?
I need to take some time to consider this and the implications.
Anyone else have any input?
> Moving the db is never a problem since it stores timezone within itself.
> Moving the server won't be problem only if it takes timezone from the db or
> always manually fixed after reallocation.
>
>
> > I am assuming that the development assumes that it is occuring in the
> > production environment (including timezone).
> >
>
> Yeah, it makes sense.
Without giving it too much thought, to me, if I programmatically create
a date Date testDate = new Date ("2011-03-15") [or whatever the
precise syntax is] then when I inspect the underlying data structures, I
expect to see a (in Java DateTime space) a cdate of "2011-03-15
0h00". Yes?
On another note: If I want to fiddle with this: i.e. globally replace all
references to the Java Date/Time/Calendar classes with JodaTime, I
assume the recommended approach is to create a subversion
branch?
Is this as simple as:
sh> svn copy https://svn.apache.org/repos/asf/incubator/isis/trunk \
https://svn.apache.org/repos/asf/incubator/isis/branches/jodatime \
-m "part one of Timezone saga - use JodaTime"
sh> svn up .../branches/jodatime
I list "trunk" above, but only a few sub-directories may be actually
required (applib, runtime and datastore, for example).
Re: Should timezone information be explicitly set (to UTC) in date/datetime/time values?
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
Ok, I've had a little time to think some more about this while I was
away.
Anyway, I realised a few things:
1) java.sql.Date is explicitly defined (in the Java docs) to be relative to
GMT. Quote:
"A thin wrapper around a millisecond value that allows JDBC to identify
this as an SQL DATE value. A milliseconds value represents the
number of milliseconds that have passed since January 1, 1970
00:00:00.000 GMT.
To conform with the definition of SQL DATE, the millisecond values
wrapped by a java.sql.Date instance must be 'normalized' by setting
the hours, minutes, seconds, and milliseconds to zero in the particular
time zone with which the instance is associated. "
The Hudson/Jenkins console output contains enough info to show the
problem in all its glory:
Test: testSqlDate() '2011-4-8'
sqlDataClass.getSqlDate() as String:2011-04-06
sqlDate.toString() as String:2011-04-07
SQL date: Test '2011-4-8', expected 2011-04-07, and got 2011-04-06.
This is with a GMT-0200 system default timezone! The date is
supposed to be 8th of April, but displays as either the 7th or the 6th,
depending on where in the code you inspect it!
What am I missing? Time to dig a little deeper...
2) While I proposed to have "a database timezone", "an application
timezone" and "a UI timezone", there is no clear separation between
"system" and "user interface" in Isis. If all UI text passed through a
common layer, then one would have an opportunity to "translate"
datetimes,etc, for timezone. But this does not happen, does it?
So, I suppose this means that ordinarily the only place that a timezone
shift could occur is when datetimes transit in/out of the datastore!
If you are writing an application with users in multiple timezones, you
must manually manage storing the user's actual timezone and
performing timezone shifts.
Re: Should timezone information be explicitly set (to UTC) in
date/datetime/time values?
Posted by Alexander Krasnukhin <th...@gmail.com>.
Kevin,
a) *two* timezone conversions need to be covered:
> datastore <-> system <-> UI
> In general, the datastore and system will have the same timezone, but
> this must not be *assumed* to be the case.
>
Yep, it must be defined somewhere explicitly.
> b) Stored date/datetime values need not (must not?) have an explicit
> timezone, as long as the datastore has a timezone (which it is assumed
> that all values in the datastore are stored in).
>
Yep
> c) Store date/datetime values *must* be stored with an explicit timezone.
>
Nope
> As long as the following can be handled - a system is built to assume
> all actions happen in a single timezone, and hence does not try and
> handle events across timezones (like a multinational meeting scheduler
> would). It must not fall over if the datastore is moved (for convenience)
> to another country - think: you currently host your webapp in the USA,
> but a cheaper provider appears in India and you choose to move... if
> you're not careful, lunch time is no longer in the middle of your day!
>
Moving the db is never a problem since it stores timezone within itself.
Moving the server won't be problem only if it takes timezone from the db or
always manually fixed after reallocation.
> I am assuming that the development assumes that it is occuring in the
> production environment (including timezone).
>
Yeah, it makes sense.
--
Regards,
Alexander
Re: Should timezone information be explicitly set (to UTC) in
date/datetime/time values?
Posted by Kevin Meyer <ke...@kmz.co.za>.
Alexander,
If I understand you correctly, you're saying:
a) *two* timezone conversions need to be covered:
datastore <-> system <-> UI
In general, the datastore and system will have the same timezone, but
this must not be *assumed* to be the case.
b) Stored date/datetime values need not (must not?) have an explicit
timezone, as long as the datastore has a timezone (which it is assumed
that all values in the datastore are stored in).
or are you saying
c) Store date/datetime values *must* be stored with an explicit timezone.
As long as the following can be handled - a system is built to assume
all actions happen in a single timezone, and hence does not try and
handle events across timezones (like a multinational meeting scheduler
would). It must not fall over if the datastore is moved (for convenience)
to another country - think: you currently host your webapp in the USA,
but a cheaper provider appears in India and you choose to move... if
you're not careful, lunch time is no longer in the middle of your day!
On Tue, March 15, 2011 12:09, Alexander Krasnukhin wrote:
> My point is that it's very common that development and production are in
> different timezones.
I am assuming that the development assumes that it is occuring in the
production environment (including timezone).
> But I don't think UTC is a good choice. Try to write correct SQL queries
> developing in GMT+7 for production in GMT+2 while db stores everything in
> UTC. Happy testing!
>
> My point is that there must be one single place to take "system common
> time
> zone" from. And it should be as close as possible to the data - db is the
> perfect choice. With this approach even xml files must have "time zone"
> property so they will show correct time in GMT+2 and GMT+7.
>
> Well, it's just my thoughts.
>
Re: Should timezone information be explicitly set (to UTC) in
date/datetime/time values?
Posted by Alexander Krasnukhin <th...@gmail.com>.
My point is that it's very common that development and production are in
different timezones.
But I don't think UTC is a good choice. Try to write correct SQL queries
developing in GMT+7 for production in GMT+2 while db stores everything in
UTC. Happy testing!
My point is that there must be one single place to take "system common time
zone" from. And it should be as close as possible to the data - db is the
perfect choice. With this approach even xml files must have "time zone"
property so they will show correct time in GMT+2 and GMT+7.
Well, it's just my thoughts.
On Tue, Mar 15, 2011 at 10:52 AM, Mike Burton <mi...@mycosystems.co.uk>wrote:
> Good point.
> If we need to cater for "the system" moving to a different timezone, then
> the "system common timezome" would need to be UTC not server-localtime.
>
>
> Best regards
>
> Mike Burton
>
>
>
>
> On 15 Mar 2011, at 09:20, Alexander Krasnukhin wrote:
>
> > Sorry to interrupt you guys, but I have one simple question. I faced this
> > problem before so I have something to say.
> >
> > We need (db + server + client) to play. They are three distinct systems
> and
> > each of them could be in different time zone. Right? So moving any of
> > components to another time zone shouldn't change the app behavior,
> doesn't
> > it? Otherwise you need to write a rule for any component relocation.
> >
> > For example if you choose server's time zone as default then moving
> server
> > to another time zone automatically invalidates all data in the db. Even
> if
> > you are using xml db the files written in GMT+2 is no valid for GMT+7. So
> > you need to manually convert all dates for the new timezone.
> >
> > Really? Changing data only because of server relocation?
> >
> > On Tue, Mar 15, 2011 at 9:40 AM, Mike Burton <mikeb@mycosystems.co.uk
> >wrote:
> >
> >> Hi Kevin,
> >>
> >>> ...understand you correctly
> >> Yes.
> >>
> >>> ...not UTC, prefer "system default".
> >> I Agree.
> >>
> >> Before any calls to cal.getTime() including
> >> the Isis applib when it calculates the Date / DateTime value, we'd need
> to
> >> call cal.setTimezone() , maybe keeping a singleton 'cal' object too.
> >>
> >> Best Regards
> >>
> >> Mike Burton
> >> ( iPhone)
> >>
> >>
> >>
> >>
> >> On 15 Mar 2011, at 07:53, "Kevin Meyer" <ke...@kmz.co.za> wrote:
> >>
> >>> Hi Mike,
> >>>
> >>>> I think dates should be stored in the timezone where the app ie server
> >> is
> >>>> running, and every input or display should convert accordingly.
> >>>> We should somewhere store / note the app / server's timezone, and
> never
> >>>> change it.
> >>>
> >>> If I understand you correctly, what you're saying is equivalent to:
> >>> a) Don't store the timezone with the date/time/datetime value,
> >>> b) Assume the stored date/time/datetime is stored according to
> >>> server defaults,
> >>> c) Find the user timezone and convert date/time/datetime only as it
> >>> transits the system <-> UI layer (i.e. only visually).
> >>>
> >>> The alternative to (c), which is to convert at the objectstore <->
> >>> system layer (i.e. all "internal" times are already converted to
> >>> an appropriate timezone) I think is unworkable..
> >>>
> >>> Anyone else?
> >>>
> >>> Perhaps an intermediate is to have a single static TimeZone instance
> >>> provided by the framework (or whichever is most appropriate) context,
> >>> that is set to what ever the application author desires - defaulting
> >>> to "system default", instead of the local UTC timezone embedded in the
> >>> applib Date/DateTime classes?
> >>>
> >>>> App would have to ascertain user's timezone (in user's preference page
> >>>> etc?) , I don't think we can get this automatically like we can for
> >> user's
> >>>> locale. We could /guess/ that its different if we see that user's
> >> /locale/
> >>>> is different to server's locale, then if we guess / suspect that it's
> >>>> different we could prompt the user to specify their timezone in their
> >>>> preference page.
> >>>
> >>> The user time zone would be stored in the user context, I guess...
> >>>
> >>>> In case of "raw" access to stored dates (or even in separate SQL
> >> queries)
> >>>> I can't see a way of enforcing this, but I guess such accesses would
> >>>> mostly be done from the server ie in the server's timezone.
> >>>
> >>> This is why all stored data needs a common timezone, I'm just not sure
> >>> it should explicitly be UTC. I think I prefer "system default".
> >>>
> >>> The issues seem to be that cal.getTime() [if memory serves]
> automatically
> >>> translates the cal timezone from (in this case, UTC) to system default
> >>> (for the returned Date). My cal.getTime() jumps 2 hours.
> >>> If memory serves, it's the cal.getTime() method that is used to create
> >>> the Isis applib Date / DateTime value.
> >>>
> >>>> All of the above should apply to Isis's "system run date" too.
> >>>>
> >>>> Would JodaTime or somesuch help?
> >>>
> >>> Is JodaTime[1] Apache compatible? Seems like:
> >>> " Apache License
> >>> Version 2.0, January 2004
> >>> http://www.apache.org/licenses/
> >>> "[2]
> >>>
> >>> Regards,
> >>> Kevin
> >>>
> >>> [1] http://joda-time.sourceforge.net/
> >>> [2] http://joda-time.sourceforge.net/license.html
> >>>
> >>>
> >>
> >>
> >
> >
> > --
> > Regards,
> > Alexander
>
>
--
Regards,
Alexander
Re: Should timezone information be explicitly set (to UTC) in date/datetime/time values?
Posted by Mike Burton <mi...@mycosystems.co.uk>.
Good point.
If we need to cater for "the system" moving to a different timezone, then the "system common timezome" would need to be UTC not server-localtime.
Best regards
Mike Burton
On 15 Mar 2011, at 09:20, Alexander Krasnukhin wrote:
> Sorry to interrupt you guys, but I have one simple question. I faced this
> problem before so I have something to say.
>
> We need (db + server + client) to play. They are three distinct systems and
> each of them could be in different time zone. Right? So moving any of
> components to another time zone shouldn't change the app behavior, doesn't
> it? Otherwise you need to write a rule for any component relocation.
>
> For example if you choose server's time zone as default then moving server
> to another time zone automatically invalidates all data in the db. Even if
> you are using xml db the files written in GMT+2 is no valid for GMT+7. So
> you need to manually convert all dates for the new timezone.
>
> Really? Changing data only because of server relocation?
>
> On Tue, Mar 15, 2011 at 9:40 AM, Mike Burton <mi...@mycosystems.co.uk>wrote:
>
>> Hi Kevin,
>>
>>> ...understand you correctly
>> Yes.
>>
>>> ...not UTC, prefer "system default".
>> I Agree.
>>
>> Before any calls to cal.getTime() including
>> the Isis applib when it calculates the Date / DateTime value, we'd need to
>> call cal.setTimezone() , maybe keeping a singleton 'cal' object too.
>>
>> Best Regards
>>
>> Mike Burton
>> ( iPhone)
>>
>>
>>
>>
>> On 15 Mar 2011, at 07:53, "Kevin Meyer" <ke...@kmz.co.za> wrote:
>>
>>> Hi Mike,
>>>
>>>> I think dates should be stored in the timezone where the app ie server
>> is
>>>> running, and every input or display should convert accordingly.
>>>> We should somewhere store / note the app / server's timezone, and never
>>>> change it.
>>>
>>> If I understand you correctly, what you're saying is equivalent to:
>>> a) Don't store the timezone with the date/time/datetime value,
>>> b) Assume the stored date/time/datetime is stored according to
>>> server defaults,
>>> c) Find the user timezone and convert date/time/datetime only as it
>>> transits the system <-> UI layer (i.e. only visually).
>>>
>>> The alternative to (c), which is to convert at the objectstore <->
>>> system layer (i.e. all "internal" times are already converted to
>>> an appropriate timezone) I think is unworkable..
>>>
>>> Anyone else?
>>>
>>> Perhaps an intermediate is to have a single static TimeZone instance
>>> provided by the framework (or whichever is most appropriate) context,
>>> that is set to what ever the application author desires - defaulting
>>> to "system default", instead of the local UTC timezone embedded in the
>>> applib Date/DateTime classes?
>>>
>>>> App would have to ascertain user's timezone (in user's preference page
>>>> etc?) , I don't think we can get this automatically like we can for
>> user's
>>>> locale. We could /guess/ that its different if we see that user's
>> /locale/
>>>> is different to server's locale, then if we guess / suspect that it's
>>>> different we could prompt the user to specify their timezone in their
>>>> preference page.
>>>
>>> The user time zone would be stored in the user context, I guess...
>>>
>>>> In case of "raw" access to stored dates (or even in separate SQL
>> queries)
>>>> I can't see a way of enforcing this, but I guess such accesses would
>>>> mostly be done from the server ie in the server's timezone.
>>>
>>> This is why all stored data needs a common timezone, I'm just not sure
>>> it should explicitly be UTC. I think I prefer "system default".
>>>
>>> The issues seem to be that cal.getTime() [if memory serves] automatically
>>> translates the cal timezone from (in this case, UTC) to system default
>>> (for the returned Date). My cal.getTime() jumps 2 hours.
>>> If memory serves, it's the cal.getTime() method that is used to create
>>> the Isis applib Date / DateTime value.
>>>
>>>> All of the above should apply to Isis's "system run date" too.
>>>>
>>>> Would JodaTime or somesuch help?
>>>
>>> Is JodaTime[1] Apache compatible? Seems like:
>>> " Apache License
>>> Version 2.0, January 2004
>>> http://www.apache.org/licenses/
>>> "[2]
>>>
>>> Regards,
>>> Kevin
>>>
>>> [1] http://joda-time.sourceforge.net/
>>> [2] http://joda-time.sourceforge.net/license.html
>>>
>>>
>>
>>
>
>
> --
> Regards,
> Alexander
Re: Should timezone information be explicitly set (to UTC) in
date/datetime/time values?
Posted by Alexander Krasnukhin <th...@gmail.com>.
Sorry to interrupt you guys, but I have one simple question. I faced this
problem before so I have something to say.
We need (db + server + client) to play. They are three distinct systems and
each of them could be in different time zone. Right? So moving any of
components to another time zone shouldn't change the app behavior, doesn't
it? Otherwise you need to write a rule for any component relocation.
For example if you choose server's time zone as default then moving server
to another time zone automatically invalidates all data in the db. Even if
you are using xml db the files written in GMT+2 is no valid for GMT+7. So
you need to manually convert all dates for the new timezone.
Really? Changing data only because of server relocation?
On Tue, Mar 15, 2011 at 9:40 AM, Mike Burton <mi...@mycosystems.co.uk>wrote:
> Hi Kevin,
>
> > ...understand you correctly
> Yes.
>
> > ...not UTC, prefer "system default".
> I Agree.
>
> Before any calls to cal.getTime() including
> the Isis applib when it calculates the Date / DateTime value, we'd need to
> call cal.setTimezone() , maybe keeping a singleton 'cal' object too.
>
> Best Regards
>
> Mike Burton
> ( iPhone)
>
>
>
>
> On 15 Mar 2011, at 07:53, "Kevin Meyer" <ke...@kmz.co.za> wrote:
>
> > Hi Mike,
> >
> >> I think dates should be stored in the timezone where the app ie server
> is
> >> running, and every input or display should convert accordingly.
> >> We should somewhere store / note the app / server's timezone, and never
> >> change it.
> >
> > If I understand you correctly, what you're saying is equivalent to:
> > a) Don't store the timezone with the date/time/datetime value,
> > b) Assume the stored date/time/datetime is stored according to
> > server defaults,
> > c) Find the user timezone and convert date/time/datetime only as it
> > transits the system <-> UI layer (i.e. only visually).
> >
> > The alternative to (c), which is to convert at the objectstore <->
> > system layer (i.e. all "internal" times are already converted to
> > an appropriate timezone) I think is unworkable..
> >
> > Anyone else?
> >
> > Perhaps an intermediate is to have a single static TimeZone instance
> > provided by the framework (or whichever is most appropriate) context,
> > that is set to what ever the application author desires - defaulting
> > to "system default", instead of the local UTC timezone embedded in the
> > applib Date/DateTime classes?
> >
> >> App would have to ascertain user's timezone (in user's preference page
> >> etc?) , I don't think we can get this automatically like we can for
> user's
> >> locale. We could /guess/ that its different if we see that user's
> /locale/
> >> is different to server's locale, then if we guess / suspect that it's
> >> different we could prompt the user to specify their timezone in their
> >> preference page.
> >
> > The user time zone would be stored in the user context, I guess...
> >
> >> In case of "raw" access to stored dates (or even in separate SQL
> queries)
> >> I can't see a way of enforcing this, but I guess such accesses would
> >> mostly be done from the server ie in the server's timezone.
> >
> > This is why all stored data needs a common timezone, I'm just not sure
> > it should explicitly be UTC. I think I prefer "system default".
> >
> > The issues seem to be that cal.getTime() [if memory serves] automatically
> > translates the cal timezone from (in this case, UTC) to system default
> > (for the returned Date). My cal.getTime() jumps 2 hours.
> > If memory serves, it's the cal.getTime() method that is used to create
> > the Isis applib Date / DateTime value.
> >
> >> All of the above should apply to Isis's "system run date" too.
> >>
> >> Would JodaTime or somesuch help?
> >
> > Is JodaTime[1] Apache compatible? Seems like:
> > " Apache License
> > Version 2.0, January 2004
> > http://www.apache.org/licenses/
> > "[2]
> >
> > Regards,
> > Kevin
> >
> > [1] http://joda-time.sourceforge.net/
> > [2] http://joda-time.sourceforge.net/license.html
> >
> >
>
>
--
Regards,
Alexander
Re: Should timezone information be explicitly set (to UTC) in date/datetime/time values?
Posted by Mike Burton <mi...@mycosystems.co.uk>.
Hi Kevin,
> ...understand you correctly
Yes.
> ...not UTC, prefer "system default".
I Agree.
Before any calls to cal.getTime() including
the Isis applib when it calculates the Date / DateTime value, we'd need to call cal.setTimezone() , maybe keeping a singleton 'cal' object too.
Best Regards
Mike Burton
( iPhone)
On 15 Mar 2011, at 07:53, "Kevin Meyer" <ke...@kmz.co.za> wrote:
> Hi Mike,
>
>> I think dates should be stored in the timezone where the app ie server is
>> running, and every input or display should convert accordingly.
>> We should somewhere store / note the app / server's timezone, and never
>> change it.
>
> If I understand you correctly, what you're saying is equivalent to:
> a) Don't store the timezone with the date/time/datetime value,
> b) Assume the stored date/time/datetime is stored according to
> server defaults,
> c) Find the user timezone and convert date/time/datetime only as it
> transits the system <-> UI layer (i.e. only visually).
>
> The alternative to (c), which is to convert at the objectstore <->
> system layer (i.e. all "internal" times are already converted to
> an appropriate timezone) I think is unworkable..
>
> Anyone else?
>
> Perhaps an intermediate is to have a single static TimeZone instance
> provided by the framework (or whichever is most appropriate) context,
> that is set to what ever the application author desires - defaulting
> to "system default", instead of the local UTC timezone embedded in the
> applib Date/DateTime classes?
>
>> App would have to ascertain user's timezone (in user's preference page
>> etc?) , I don't think we can get this automatically like we can for user's
>> locale. We could /guess/ that its different if we see that user's /locale/
>> is different to server's locale, then if we guess / suspect that it's
>> different we could prompt the user to specify their timezone in their
>> preference page.
>
> The user time zone would be stored in the user context, I guess...
>
>> In case of "raw" access to stored dates (or even in separate SQL queries)
>> I can't see a way of enforcing this, but I guess such accesses would
>> mostly be done from the server ie in the server's timezone.
>
> This is why all stored data needs a common timezone, I'm just not sure
> it should explicitly be UTC. I think I prefer "system default".
>
> The issues seem to be that cal.getTime() [if memory serves] automatically
> translates the cal timezone from (in this case, UTC) to system default
> (for the returned Date). My cal.getTime() jumps 2 hours.
> If memory serves, it's the cal.getTime() method that is used to create
> the Isis applib Date / DateTime value.
>
>> All of the above should apply to Isis's "system run date" too.
>>
>> Would JodaTime or somesuch help?
>
> Is JodaTime[1] Apache compatible? Seems like:
> " Apache License
> Version 2.0, January 2004
> http://www.apache.org/licenses/
> "[2]
>
> Regards,
> Kevin
>
> [1] http://joda-time.sourceforge.net/
> [2] http://joda-time.sourceforge.net/license.html
>
>
Re: Should timezone information be explicitly set (to UTC) in
date/datetime/time values?
Posted by Kevin Meyer <ke...@kmz.co.za>.
Hi Mike,
> I think dates should be stored in the timezone where the app ie server is
> running, and every input or display should convert accordingly.
> We should somewhere store / note the app / server's timezone, and never
> change it.
If I understand you correctly, what you're saying is equivalent to:
a) Don't store the timezone with the date/time/datetime value,
b) Assume the stored date/time/datetime is stored according to
server defaults,
c) Find the user timezone and convert date/time/datetime only as it
transits the system <-> UI layer (i.e. only visually).
The alternative to (c), which is to convert at the objectstore <->
system layer (i.e. all "internal" times are already converted to
an appropriate timezone) I think is unworkable..
Anyone else?
Perhaps an intermediate is to have a single static TimeZone instance
provided by the framework (or whichever is most appropriate) context,
that is set to what ever the application author desires - defaulting
to "system default", instead of the local UTC timezone embedded in the
applib Date/DateTime classes?
> App would have to ascertain user's timezone (in user's preference page
> etc?) , I don't think we can get this automatically like we can for user's
> locale. We could /guess/ that its different if we see that user's /locale/
> is different to server's locale, then if we guess / suspect that it's
> different we could prompt the user to specify their timezone in their
> preference page.
The user time zone would be stored in the user context, I guess...
> In case of "raw" access to stored dates (or even in separate SQL queries)
> I can't see a way of enforcing this, but I guess such accesses would
> mostly be done from the server ie in the server's timezone.
This is why all stored data needs a common timezone, I'm just not sure
it should explicitly be UTC. I think I prefer "system default".
The issues seem to be that cal.getTime() [if memory serves] automatically
translates the cal timezone from (in this case, UTC) to system default
(for the returned Date). My cal.getTime() jumps 2 hours.
If memory serves, it's the cal.getTime() method that is used to create
the Isis applib Date / DateTime value.
> All of the above should apply to Isis's "system run date" too.
>
> Would JodaTime or somesuch help?
Is JodaTime[1] Apache compatible? Seems like:
" Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
"[2]
Regards,
Kevin
[1] http://joda-time.sourceforge.net/
[2] http://joda-time.sourceforge.net/license.html
Re: Should timezone information be explicitly set (to UTC) in date/datetime/time values?
Posted by Mike Burton <mi...@mycosystems.co.uk>.
Hi Kevin,
I think dates should be stored in the timezone where the app ie server is running, and every input or display should convert accordingly.
We should somewhere store / note the app / server's timezone, and never change it.
App would have to ascertain user's timezone (in user's preference page etc?) , I don't think we can get this automatically like we can for user's locale. We could /guess/ that its different if we see that user's /locale/ is different to server's locale, then if we guess / suspect that it's different we could prompt the user to specify their timezone in their preference page.
In case of "raw" access to stored dates (or even in separate SQL queries) I can't see a way of enforcing this, but I guess such accesses would mostly be done from the server ie in the server's timezone.
All of the above should apply to Isis's "system run date" too.
Would JodaTime or somesuch help?
Best regards
Mike Burton
On 14 Mar 2011, at 16:10, Kevin Meyer - KMZ wrote:
> Hi guys,
>
> My old bug-bear is back!!
>
> I am experiencing some grief because the Isis applib Date, DateTime
> and java.sql.Date (and their value semantic providers) explicitly use an
> internal timezone of UTC.
>
> This impact on datastores or anyone creating a date directly.
>
> I've raised this before (a few years ago, if memory serve), but never
> reached a resolution..
>
> If the timezone is set to UTC, then all dates (and date times) seem to
> be interpreted as in this time zone. This causes problems for me, with
> my national (constant) GMT+2 offset, and anyone else not on GMT.
>
> One impact is that if I create a java.sql.Date, I must explicitly create it
> via a Calender with a UTC time zone. Simply creating a java.sql.date
> using "java.sql.date.valueOf("2010-03-05")" returns a value that does
> not compare with applib's Date.
>
> Another impact: Relative comparisons don't work!
> A simple proof (please check my logic): If I create an applib Date:
> Date applibDate = new Date(2010, 3, 5);
> and a DateTime:
> DateTime dateTime = new DateTime(2010, 3, 5, 1, 23);
> Then the comparison:
> dateTime.dateValue().after(date.dateValue())
> Fails, because I am at GMT+2!
>
> However, If I change the DateTime to 02h23, then it passes!
>
> This occurs because, deeper down, the Date value is stored (for me)
> as: 2010-03-05, 02h00
> I can get partial happiness with java.sql.Date if I remove the explicit
> setting of the time zone to UTC in the appropriate value semantic
> provider (JavaSqlDateValueSemanticsProvider), but then the xml
> object store breaks!
> By success, I mean that a new java.sql.Date of 3rd March has a cdate
> of "2010-03-05 0h00".
>
> People living in GMT will not be affected (until daylight savings time?)
>
> Symptomatically, this should mean that anyone with a timezone west
> of GMTcreating a applib date (or maybe just java.sql.date) should get
> a date of the previous day!
>
>
> In both the SQL and the XML object stores, dates are not stored with
> an explicit time zone (meaning, 2010-01-01 is 2010-01-01, whether
> you're in Japan or Hawaii), so you can't safely assume one?!?
>
> If you're writing an application that manages meetings (for example)
> and the participants span multiple time-zones, then I think you need to
> handle time zones specially carefully, and in your application/domain
> code?
>
> If you don't particularly care about comparing times that are (explicitly)
> in different time zones, Date, DateTime and java.sql.Date should just
> work!
>
> Comments anyone? Should Isis internal Dates (and DateTimes, etc)
> explicitly be based on a timezone set to UTC?
>
>
> Kevin
>