Timezones

[danstiner]

Small problem we were discussing tonight.

Java date objects and app engine in general uses the utc timezone, while our target audience is in the America/Chicago timezone.

Doing some thinking/research though, I don't think we actually need to worry much about this.

When sending a date from a servlet to jsp template, it is best to use the java Date object: new PageBuilder(Page.datexample, "examples").setAttribute("date", new Date());

Technically this date object is in UTC, which we don't want the end user to see.

But the magic of a the jstl template library comes in here in the jsp: <%@ page contentType="text/html;charset=UTF-8" language="java" isELIgnored="false" %> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>

This actually prints out the localized time, so for a web-browser in Iowa it will translate the UTC date attribute to a America/Chicago timezone html output. No other effort needed. Pretty neat eh? The library looks at a locale header sent from the browser to do the date formatting correctly. Reference on how this majic works: http://www.ibm.com/developerworks/java/library/j-jstl0415/

That leaves us with only one other problem, dates being submitted into servlets. These submitted dates will probably be in some non UTC timezone like America/Chicago, so our date parsing code I think should just look at these locale headers from the users' browser to determine the correct timezone to parse the submitted dates in.

This all requires no changes to existing jsp's or the mobile app, only slight additions with server-side date parsing to take into account time zones.

[danstiner]

Feel free to comment with dissension about how complicated this sounds or alternatives :)

[twegter]

Problem is that it doesn't format to a local timezone in many systems. For example, on my system, if I want to get the system timezone, it tells me the system timezone is UTC, making it unsafe to assume the local timezone can be retrieved. This matters because there are more than one instances where we ant the user to view a time (like when something was generated) and this should be in their timezone.

"This actually prints out the localized time, so for a web-browser in Iowa it will translate the UTC date attribute to a America/Chicago timezone html output. No other effort needed. Pretty neat eh? The library looks at a locale header sent from the browser to do the date formatting correctly. Reference on how this majic works: http://www.ibm.com/developerworks/java/library/j-jstl0415/"

While this may be how it's supposed to work, in practice, it doesn't. Back when we were developing the first version of the app we had the same issue (that the local timezone is often wrong).

We already put a good amount of time into this for the first revision, so stop wasting time and just throw in the timzone set tag before you print. This fixes everything. (I can show you that it prints wrong if you don't include it).

It also doesn't matter what timezone the info is submitted in because they are all relative. Whether the event is 9am EST or CST, it's still 9am, and fortunately, javascript can get the local time accurately, so tardies, etc will be relative to the time submitted for an event. This is only an issue for when we want the server to print the current time or when something was autogenerated to the user.

-Todd

On Tue, May 22, 2012 at 11:38 PM, Daniel Stiner < reply@reply.github.com

wrote:

Small problem we were discussing tonight.

Java date objects and app engine in general uses the utc timezone, while our target audience is in the America/Chicago timezone.

Doing some thinking/research though, I don't think we actually need to worry much about this.

When sending a date from a servlet to jsp template, it is best to use the java Date object: new PageBuilder(Page.datexample, "examples").setAttribute("date", new Date());

Technically this date object is in UTC, which we don't want the end user to see.

But the magic of a the jstl template library comes in here in the jsp: <%@ page contentType="text/html;charset=UTF-8" language="java" isELIgnored="false" %> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>

This actually prints out the localized time, so for a web-browser in Iowa it will translate the UTC date attribute to a America/Chicago timezone html output. No other effort needed. Pretty neat eh? The library looks at a locale header sent from the browser to do the date formatting correctly. Reference on how this majic works: http://www.ibm.com/developerworks/java/library/j-jstl0415/

That leaves us with only one other problem, dates being submitted into servlets. These submitted dates will probably be in some non UTC timezone like America/Chicago, so our date parsing code I think should just look at these locale headers from the users' browser to determine the correct timezone to parse the submitted dates in.

This all requires no changes to existing jsp's or the mobile app, only slight additions with server-side date parsing to take into account time zones.

---

Reply to this email directly or view it on GitHub: https://github.com/curtisullerich/attendance/issues/22

Todd Wegter Iowa State University of Science & Technology Computer Engineering Undergraduate PrISUm Solar Car Team - Assistant Electrical Team Leader Developmental Robotics Laboratory - Undergraduate Researcher twegter@iastate.edu

[danstiner]

First off, I'm sorry and you are correct Todd, my reference about automatic timezones in jstl is wrong. I will help add a setTimeZone to each page that using date formatting.

However, for dealing with submitted dates, I think it still does make sense to convert everything from the submitted timezone into UTC internally. That is standard practice, and that's why app engine uses UTC as the default timezone.

Previously you guys kept your own date so everything was relative all the way through and then converted app engine's UTC date to chicago time when you needed to do comparisons with the server time. That is another way to do it, which you were talking about in your last paragraph I think.

So to summarize the two approaches:

1. Use a relative date throughout stored in a custom date class, meaning the date is stored in the datastore as localized time, dates submitted from the user are in local time and are not changed, displaying dates through jsp's does not require any timezone setting as everything is already in local time. The only issue as you know is comparing with the server's time, which requires a timezone translation.
2. Always keep time in UTC internally / in the datastore by using java's Calendar / Date, and use setTimeZone tags to translate it into the local timezone when generating html. Also dates submitted from user forms need to be translated from the local timezone they were submitted in to UTC time for storing on the server.

[twegter]

Ok, that makes sense. Does this mean that the mobile app needs to upload UTC? Right now it uploads local time. Should we upload local time with a timezone tag?

Thanks, Dan.

On Wed, May 23, 2012 at 11:46 PM, Daniel Stiner < reply@reply.github.com

wrote:

First off, I'm sorry and you are correct Todd, my reference about automatic timezones in jstl is wrong. I will help add a setTimeZone to each page that using date formatting.

However, for dealing with submitted dates, I think it still does make sense to convert everything from the submitted timezone into UTC internally. That is standard practice, and that's why app engine uses UTC as the default timezone.

Previously you guys kept your own date so everything was relative all the way through and then converted app engine's UTC date to chicago time when you needed to do comparisons with the server time. That is another way to do it, which you were talking about in your last paragraph I think.

So to summarize the two approaches:

1. Use a relative date throughout stored in a custom date class, meaning the date is stored in the datastore as localized time, dates submitted from the user are in local time and are not changed, displaying dates through jsp's does not require any timezone setting as everything is already in local time. The only issue as you know is comparing with the server's time, which requires a timezone translation.
2. Always keep time in UTC internally / in the datastore by using java's Calendar / Date, and use setTimeZone tags to translate it into the local timezone when generating html. Also dates submitted from user forms need to be translated from the local timezone they were submitted in to UTC time for storing on the server.

---

Reply to this email directly or view it on GitHub: https://github.com/curtisullerich/attendance/issues/22#issuecomment-5890697

Todd Wegter Iowa State University of Science & Technology Computer Engineering Undergraduate PrISUm Solar Car Team - Assistant Electrical Team Leader Developmental Robotics Laboratory - Undergraduate Researcher twegter@iastate.edu

[danstiner]

Yeah, its not an easy issue to deal with, and not one I've ever dealt with. ideally if the mobile app knows its local timezone it should either include that or upload in UTC.

But... for now we could just have the server assume data from the user/mobile app is in the timezone set on AppData, and eventually add a field to the app settings to set the app timezone.