Timezone issue in webapp

Question

I want to know a best practice of dealing with timezone in web app. Let take an example, Server is in UTC timezone, user1 and user2 both are in different time zone. what is a proper way to deal with date?

1. When user1 add a new date it is in different timezone and Server is in UTC so should I convert date to UTC and store in database?

2. When displaying date fetch date which is in UTC format and then convert it according to client timezone and show it. Is it proper way?

3. What is DST issue? is it effect this process?

4. Somewhere I read that store date in mili seconds only is it good idea? right now I store as a date/time.

5. is there any proper method or library to do this please suggest

My issue is

client with GMT +5:30 create a record and set delivery date and time let say june 30 2014 11:30 PM GMT +5:30

So Transporter with GMT -3:00 can see a exact local time in GMT -3:00 which client select. How to achieve this ?

Answer 1

1

Yes. Usually best practice is to store all your date-time values in UTC. Your business logic should work in UTC.

You may want to also store the value input by user or outside data source as an audit trail or debugging aid. But use UTC for the official record.

Yes the server's time zone should be set to UTC (or, if not possible, use Reykjavík Iceland). But do not depend on this in your programming. Specify your desired time zone in your code rather than rely on defaults.

2

Yes. Convert to a localized time for presentation. Unless, of course, the user prefers UTC.

Think of it as part of localization. When you internationalize, you work with key values in your code. Then upon presentation, you use the key value to look up a localized translation string to display to the user.

3

Non-issue. If by "DST" you mean Daylight Saving Time, the use of a decent date-time library will automatically handle adjustments for DST. Caveat: you need to keep the time zone definition list used by your library up-to-date as governments frequently change the rules.

If adjusting for DST (or time zones) causes confusion or misinformation with your users, then you should be displaying UTC in that case.

4

No. Do not store or work with milliseconds in most cases. Databases and date-time libraries may do so internally, but you should not.

Some nerdy types will suggest tracking milliseconds. But working with date-time as milliseconds is like working with text as byte arrays. We use libraries of code with higher levels of abstraction to handle all the complexities of text (UTF-8, Unicode normalization of diacriticals, etc.) and add helpful methods (search, replace, etc.). So it is with date-time.

Furthermore, using milliseconds will cause confusion and make debugging difficult as you cannot readily make sense of their value. Date-time work is inherently tricky and error-prone. Using milliseconds does not help.

And not all databases and other libraries use milliseconds internally. Some use whole seconds, or microseconds, or nanoseconds. Nor do they all use the same epoch.

5

In Java we have two good date-time libraries: Joda-Time and java.time (Java 8).

The java.time package was inspired by Joda-Time but is re-architected. They share similar concepts, but are not identical. You can use both in your code as long as you are careful with your import statements. Both have their own strengths and weaknesses.

Avoid j.u.Date/.Calendar

Do not use the java.util.Date and .Calendar classes bundled with Java. They are notoriously troublesome, flawed both in design and in implementation. They have been supplanted by Sun/Oracle with the new java.time package.

Both Joda-Time and java.time include handy methods to translate to/from a java.util.Date object for when some other class requires a j.u.Date object.

Bonus Tips

Regarding text formats:

• Avoid that string format you used in your question. It is unwieldy and difficult to parse.
• Learn about using various string formats defined by the ISO 8601 standard for textual representations of date-time values.
• Do not drop that leading zero in the offsets, as you did in your question. That will break code in libraries, and violates standards requirements. Always write +05:30, never +5:30. Make that a habit even when writing prose, not just in your programming code.

Example Code

Example code with Joda-Time 2.3.

Instantiate the date-time, local to a +05:30 offset. I arbitrarily chose Kolkata time zone. You would replace with appropriate one of course.

DateTimeZone timeZoneKolkata = DateTimeZone.forID( "Asia/Kolkata" );
DateTime dateTimeKolkata = new DateTime( 2014, DateTimeConstants.JUNE, 30, 23, 30, 0, timeZoneKolkata );

Adjust the same moment to another time zone with a -03:00 offset. I arbitrarily chose America/Buenos_Aires.

DateTimeZone timeZoneBuenos_Aires = DateTimeZone.forID( "America/Buenos_Aires" );
DateTime dateTimeBuenos_Aires = dateTimeKolkata.withZone( timeZoneBuenos_Aires );

Convert to UTC.

DateTime dateTimeUtc = dateTimeKolkata.withZone( DateTimeZone.UTC );