YAML Dates off by 4 hours

345 views
Skip to first unread message

alotatakada

unread,
Jun 27, 2011, 9:03:33 PM6/27/11
to play-framework
In YAML I have:

Event(green_day_flyer):
source: eventful
venue: silver_lake_lounge
category: music
start: 2012-06-30T20:00:00

This results with a field in my MySQL database as follows:

2012-06-30 16:00:00

This is my field in the Model:
@Required
@InFuture
@Temporal(TemporalType.TIMESTAMP)
public Date start;

And my in application.conf:
date.format=yyyy-MM-dd'T'hh:mm:ss


Everything is being run on my local laptop, so have no idea why this
is happening. Also, I save a date through an Action, it saves with the
appropriate time.

Does anyone know why this would be happening? I imagine its a timezone
thing, but I haven't found anything in the tutorial or in the Google
Group that explains how to deal with timezone issues.

Thanks!
Paul

Adam Jorgensen

unread,
Jun 28, 2011, 12:27:04 AM6/28/11
to play-fr...@googlegroups.com
Well, in our application (Which is admittedly not a Play app) we recently added timezones and this is something
that you have to do right.

Our app allows for the concept of timezone-naive and timezone-aware datetimes. Datetimes that are timezone aware
are accompanied by a field that stores the Olson name of the timezone. Datetimes themselves are stored in their UTC
form.

For timezone-aware datetimes:

On the UI side our app attempts to determine the client timezone using the browser (Which usually works at this point).

Datetimes submitted by the client of a local datetime along with the timezone.

On the server this is converted to UTC + timezone before being stored.

When retrieved the UTC datetime + timezone is transformed into the relevant local datetime + timezone before the client sees it.

For timezone-naive datetimes:

Everything is basically the same except the timezone is basically hard-locked to the local timezone of the server.


Another thing to note is that some databases (Postgresql) understand the concept of a timezone aware datetime and support it,
while others do not.

Finally, what is the timezone of your local laptop?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.


alotatakada

unread,
Jun 28, 2011, 1:21:31 AM6/28/11
to play-framework
My Laptop (and I) are using Eastern Time, so I'm GMT - 4... which
indicates where being off by 4 hours is coming from.

So I guess when using YAML it thinks all the Datetimes are in GMT, and
thus is translating it automatically to my local timezone. Is there a
way to try and stop it from being Smart like that?

Thanks for the explanation on how you approach timezones.


On Jun 28, 12:27 am, Adam Jorgensen <adam.jorgensen...@gmail.com>
wrote:
> Well, in our application (Which is admittedly not a Play app) we recently
> added timezones and this is something
> that you have to do right.
>
> Our app allows for the concept of timezone-naive and timezone-aware
> datetimes. Datetimes that are timezone aware
> are accompanied by a field that stores the Olson name of the timezone.
> Datetimes themselves are stored in their UTC
> form.
>
> For timezone-aware datetimes:
>
> On the UI side our app attempts to determine the client timezone using the
> browser (Which usually works at this point).
>
> Datetimes submitted by the client of a local datetime along with the
> timezone.
>
> On the server this is converted to UTC + timezone before being stored.
>
> When retrieved the UTC datetime + timezone is transformed into the relevant
> local datetime + timezone before the client sees it.
>
> For timezone-naive datetimes:
>
> Everything is basically the same except the timezone is basically
> hard-locked to the local timezone of the server.
>
> Another thing to note is that some databases (Postgresql) understand the
> concept of a timezone aware datetime and support it,
> while others do not.
>
> Finally, what is the timezone of your local laptop?

Adam Jorgensen

unread,
Jun 28, 2011, 2:10:49 AM6/28/11
to play-fr...@googlegroups.com
Actually, the project in question is a Python app so we use a mix of pytz and dateutil
but they handle roughly the same things as joda (Which I remember as being pretty neat)

On 28 June 2011 07:22, alotatakada <paul...@gmail.com> wrote:
Are you using Joda time out of curiosity?

- Paul


On Jun 28, 12:27 am, Adam Jorgensen <adam.jorgensen...@gmail.com>
wrote:
> Well, in our application (Which is admittedly not a Play app) we recently
> added timezones and this is something
> that you have to do right.
>
> Our app allows for the concept of timezone-naive and timezone-aware
> datetimes. Datetimes that are timezone aware
> are accompanied by a field that stores the Olson name of the timezone.
> Datetimes themselves are stored in their UTC
> form.
>
> For timezone-aware datetimes:
>
> On the UI side our app attempts to determine the client timezone using the
> browser (Which usually works at this point).
>
> Datetimes submitted by the client of a local datetime along with the
> timezone.
>
> On the server this is converted to UTC + timezone before being stored.
>
> When retrieved the UTC datetime + timezone is transformed into the relevant
> local datetime + timezone before the client sees it.
>
> For timezone-naive datetimes:
>
> Everything is basically the same except the timezone is basically
> hard-locked to the local timezone of the server.
>
> Another thing to note is that some databases (Postgresql) understand the
> concept of a timezone aware datetime and support it,
> while others do not.
>
> Finally, what is the timezone of your local laptop?

Dirk

unread,
Jun 29, 2011, 12:00:40 PM6/29/11
to play-fr...@googlegroups.com
Try putting quotes around the date:

Event(green_day_flyer):
   source:              eventful
   venue:               silver_lake_lounge
   category:           music
   start:                 '2012-06-30T20:00:00'


alotatakada

unread,
Jun 30, 2011, 4:16:39 AM6/30/11
to play-framework
I tried putting quotes around the date as you specified, but when i do
that the field ends up just being stored as NULL.

Dirk

unread,
Jun 30, 2011, 2:54:02 PM6/30/11
to play-fr...@googlegroups.com
Try using the canonical date format for play:
public class DateBinder implements TypeBinder<Date> {
    public static final String ISO8601 = "'ISO8601:'yyyy-MM-dd'T'HH:mm:ssZ";
    ...

alotatakada

unread,
Jun 30, 2011, 5:05:45 PM6/30/11
to play-framework
I put exactly what you typed earlier (both with and without quotes):

Event(green_day_flyer):
source: eventful
venue: silver_lake_lounge
category: music
start: '2012-06-30T20:00:00'

How would I type the date differently so that it will fit the
Canonical requirements?

Thanks,
Paul

Dirk

unread,
Jun 30, 2011, 6:05:41 PM6/30/11
to play-fr...@googlegroups.com
Try setting this in your application.conf:
date.format=yyyy-MM-dd'T'HH:mm:ss

alotatakada

unread,
Jul 2, 2011, 4:48:07 PM7/2/11
to play-framework
My conf throughout has been:

date.format=yyyy-MM-dd'T'hh:mm:ss

I don't know if this would make a difference or not, but I tried
switching the "hh" to uppercase as you show, but it still makes no
difference. The hours keep shifting versus just being stored as I
passed them.

- Paul

alotatakada

unread,
Jul 2, 2011, 6:25:21 PM7/2/11
to play-framework
Ok, so I went back, and tried putting single quotes (') around the
dates and after changing my app.conf to have "HH" listed instead of
lowercase "hh" and the dates are now being stored correctly, without a
4 hour time shift.

So to reiterate... if you put single quotes around your dates in YAML,
but your application.conf is set as:

date.format=yyyy-MM-dd'T'hh:mm:ss

All your dates will be stored as "NULL"

However, if you have your application.conf set as:

date.format=yyyy-MM-dd'T'HH:mm:ss

Everything works great!

Thanks for your help Dirk!

- Paul
> > > > > > > InYAMLI have:

rajish

unread,
Jul 14, 2011, 9:59:56 AM7/14/11
to play-framework
The default (generated by play or scaffolding - I don't know) format
in my application.conf was

date.format=yyyy-MM-dd

Which made me a lot of trouble with submitting (unchanged) timestamp
data. Thanks to this thread I've solved the problem. Now the time
value stays unchanged after record update.

Could someone explain what other side effects changing the setting can
cause?

- Rajish
> > > > > Try using the canonical dateformatfor play:
Reply all
Reply to author
Forward
0 new messages