2

What are the benefits of providing a date string with offset value (such as +0530) instead of specifying its timezone separately as a TimeZone display name (such as Asia/Calcutta)?

Ezil Kannan
  • 63
  • 3
  • BTW, the restored pre-colonial name for Calcutta is now available as identifier for that time zone: `Asia/Kolkata` – Basil Bourque Jun 29 '17 at 15:47
  • Actually both are available as synonyms - in Java 8 they have the same rules: `ZoneId.of("Asia/Calcutta").getRules().equals(ZoneId.of("Asia/Kolkata").getRules())` is `true`. In Joda-Time `DateTimeZone.forID("Asia/Kolkata") == DateTimeZone.forID("Asia/Calcutta")` is also `true`. In IANA tz files I also found an entry linking both (so they're considered the same). –  Jun 29 '17 at 17:04

1 Answers1

2

Summary

The offset tells you exactly what's the date and time relative to UTC, so it's non-ambiguous. And the timezone tells you which rules this date is following (so you can deduce if it's in DST or not).

Details

I wouldn't say there are benefits, but there are differences when you use one or another.

An offset is just the difference from UTC: +0530 means "5 hours and 30 minutes ahead of UTC".

A timezone is a list of all different offsets that a region had during its history. For Asia/Calcutta timezone, the history (at least the one I've got in Java 8) is:

  • before 1880: the offset was +05:53:28 (before UTC was invented, each city had its own local time, leading to these strange offsets)
  • from 1880 to 1941: it used the offset +05:53:20
  • on 1941-10-01 it changed to +06:30
  • on 1942-05-15 it changed to +05:30
  • on 1942-09-01, DST started and the offset became +06:30
  • on 1945-10-15, DST ended and the offset was set back to +05:30
  • since then, the offset is +05:30, without DST changes

The main differences between using a timezone and a offset are listed below. I'm also giving some examples in Java 8, just to ilustrate better:

  1. if you use a timezone, the offset will be "calculated" based on its history and the valid offset at that date and time

Example: creating some dates in Asia/Calcutta timezone:

// get the timezone
ZoneId zone = ZoneId.of("Asia/Calcutta");

// 1941-10-01 - when the offset changed to `+06:30`
System.out.println(ZonedDateTime.of(1941, 10, 1, 10, 0, 0, 0, zone)); // 1941-10-01T10:00+06:30[Asia/Calcutta]

// 2017 - the current offset is `+05:30`
System.out.println(ZonedDateTime.of(2017, 10, 1, 10, 0, 0, 0, zone)); // 2017-10-01T10:00+05:30[Asia/Calcutta]

The output is:

1941-10-01T10:00+06:30[Asia/Calcutta]
2017-10-01T10:00+05:30[Asia/Calcutta]

In the first case, the date is 1941-10-01 (when the offset changed to +06:30), so the API checks the timezone history and gets the valid offset at that date.

The same happens for the second case (2017-10-01) - it gets the valid offset for this date, which is +05:30.

There's more: if I get one day before 1941-10-01, the offset will be the previous one (according to the timezone history, before 1941-10-01, the offset was +05:53:20):

ZonedDateTime z = ZonedDateTime.of(1941, 10, 1, 10, 0, 0, 0, zone);
System.out.println(z.minusDays(1)); // 1941-09-30T10:00+05:53:20[Asia/Calcutta]

The output is:

1941-09-30T10:00+05:53:20[Asia/Calcutta]

Note that the offset changed automatically. The API checks the timezone history and sees that one day before (1941-09-30), the offset was different and do the adjustment accordingly.

  1. if you use an offset, you can't say in what timezone you are, because there can be more than one timezone that uses this offset at that time - check this list to see how many timezones can use the same offsets at the same time.

Example: creating a date in 1941-10-01 with offset 06:30 and get the previous date

ZonedDateTime zdt = ZonedDateTime.of(1941, 10, 1, 10, 0, 0, 0, ZoneId.of("+06:30"));
System.out.println(zdt); // 1941-10-01T10:00+06:30
System.out.println(zdt.minusDays(1)); // 1941-09-30T10:00+06:30

The output is:

1941-10-01T10:00+06:30
1941-09-30T10:00+06:30

Note the difference from the previous example. Both dates have the offset +06:30. That's because I'm not using a timezone, so there's no history to check and the offset will never change.

IMO, there's no "better" solution, only differences between each approach. You must choose what's best for each case.

Community
  • 1
  • 1
  • Ok. I'm looking for a good non ambiguous representation of date string. Correct me if I'm wrong, for representing past dates, TimeZone name is better to avoid ambiguity. Will it also be non ambiguous if I use it to refer future dates. For example if I say that an event starts at 2040-06-25T10:00:00 Asia/Calcutta, will it be non ambiguous even if DST is adopted some time in future? – Ezil Kannan Jun 29 '17 at 14:31
  • I recommend to write both the offset and the timezone (such as `2040-06-25T10:00:00 +05:30 Asia/Calcutta`). That's because when DST ends, clocks shift back (usually by 1 hour) and there might be 2 offsets for the same date/time. Example: in São Paulo, the offset during DST is `-02:00`. DST ended at `2017-02-19T00:00-02:00`, so the clocks went back to `2017-02-18T23:00-03:00`. So, this datetime `2017-02-18T23:00` existed in 2 offsets: `-02:00` (during DST) and `-03:00` (after DST ends). To avoid ambiguity, both the offset and the timezone are required. –  Jun 29 '17 at 14:39
  • 2
    The offset tells you exactly what's the date and time relative to UTC, so it's non-ambiguous. And the timezone tells you which rules this date is following (so you can deduce if it's in DST or not). –  Jun 29 '17 at 14:40
  • 2
    @Hugo I suggest pasting that last comment of yours at the top of your Answer with a heading of "Summary". Very succinct and well-put. – Basil Bourque Jun 29 '17 at 16:01