Java – Common format for time zone in Java/J2me

dstjavajava-mesynctimezone

We are developing a j2me app for syncing contacts to/from a server. we are storing the update and create time (long mill sec) with each contact for conflict resolution/sync calculations.

Now as the client and server app can be in different time zones , how one can store time with time zone in a standard format (to take care diff time zones and daylight savings) for calculations at client and server side.

Best Solution

If you use System.currentTimeMillis() you don't have to worry about time zones, because it is in universal time. From System.currentTimeMillis() Javadoc:

public static long currentTimeMillis()

[...]

Returns: the difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC.

The time zone UTC is Coordinated Universal Time, which is mostly GMT .

Related Solutions

Java – How does the Java ‘for each’ loop work

for (Iterator<String> i = someIterable.iterator(); i.hasNext();) {
    String item = i.next();
    System.out.println(item);
}

Note that if you need to use i.remove(); in your loop, or access the actual iterator in some way, you cannot use the for ( : ) idiom, since the actual iterator is merely inferred.

As was noted by Denis Bueno, this code works for any object that implements the Iterable interface.

Also, if the right-hand side of the for (:) idiom is an array rather than an Iterable object, the internal code uses an int index counter and checks against array.length instead. See the Java Language Specification.

Javascript – Getting the client’s time zone (and offset) in JavaScript

Using an offset to calculate Timezone is a wrong approach, and you will always encounter problems. Time zones and daylight saving rules may change on several occasions during a year, and It's difficult to keep up with changes.

To get the system's IANA timezone in JavaScript, you should use

console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)

As of September 2019, this works in 95% of the browsers used globally.

Old compatibility information

ecma-402/1.0 says that timeZone may be undefined if not provided to constructor. However, future draft (3.0) fixed that issue by changing to system default timezone.

In this version of the ECMAScript Internationalization API, the timeZone property will remain undefined if no timeZone property was provided in the options object provided to the Intl.DateTimeFormat constructor. However, applications should not rely on this, as future versions may return a String value identifying the host environment’s current time zone instead.

in ecma-402/3.0 which is still in a draft it changed to

In this version of the ECMAScript 2015 Internationalization API, the timeZone property will be the name of the default time zone if no timeZone property was provided in the options object provided to the Intl.DateTimeFormat constructor. The previous version left the timeZone property undefined in this case.