1

I need to record the time of different systems whose default behavior would convert the input time into the systems' timezone. While what I want is to disable the convert. So in system 1, I need to construct a Calendar whose timezone is same with the system 2. For example, system 1's default timezone is PDT, system 2's default timezone is GMT, the time needed to create calendar is 2011/08/23 4:00 in PDT, what I need is to create a calendar in system 1 like 2011/08/23 4:00 in GMT.

In other words, How to create a Calendar without the concept of Timezone

Bindi
  • 11
  • 1
  • 2

7 Answers7

6

I would abandon java.util.{Date, Calendar} at this point and flee to the comfort of Joda Time, where you would create a LocalDateTime. (Joda Time is a far superior date/time API.)

If you really want to stick with Calendar, you can just use the same time zone everywhere - the simplest approach being UTC as that doesn't have any daylight saving time.

Alternatively, it's not clear that you really want a Calendar without the concept of a TimeZone - but a Calendar which uses a TimeZone other than the system default - which is easy; you just set the time zone for the calendar explicitly. Of course you need to know the time zone of the other system that way...

If you can give more details of what information you know and what you need to do with it, we may be able to help you more.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • It's quite ironic that the correct classes to use for a date/time *without* a timezone are called LocalDate and LocalDateTime... – Michael Borgwardt Aug 23 '11 at 08:32
  • 1
    @Michael: Yes, I've ruminated about that myself before now. It's "local wherever you are" rather than "tied to a specific locality". – Jon Skeet Aug 23 '11 at 08:35
  • As if other Joda classes/methods are supposed to have intuitive and consistent names? – jarnbjo Aug 23 '11 at 08:49
  • @jarnbjo: For the most part I think they're okay. I'm interested in making Noda Time have the most intuitive names possible though, so if there are any which seem particularly bad to you, I'd love to hear about them. Feel free to drop me a mail (skeet@pobox.com) if your thoughts aren't really suitable for SO comments :) – Jon Skeet Aug 23 '11 at 08:59
  • E.g. class naming: DateTimeParser, DateTimePrinter, DateTimeFormat, DateTimeFormatter. What's the intuitive purpose of these classes and why is DateTimeFormatter used to parse strings and not DateTimeParser? Method naming: the parseMillis method in DateTimeFormatter has a different semantic than the other parseXyz methods? – jarnbjo Aug 23 '11 at 19:00
  • @jarnbjo: I agree that those aren't great names - I'm currently trying to think of better ones myself :) – Jon Skeet Aug 23 '11 at 19:01
3

Calendar from the definition is a date in some calendar system (typically Gregorian) and in a specified TimeZone.

If you don't care about time zone (or more precisely: you want points in time regardless of time zone), simply use Date. Despite its name, it actually stores the exact moment in time, not a date in some calendar.

Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
  • But the OP doesn't *want* an exact instant in time as far as I can tell - because 2011/08/23 4:00 GMT isn't the same instant as 2011/08/23 4:00 PDT. – Jon Skeet Aug 23 '11 at 08:36
2

How about just using the long epoch time returned from System.currentTimeMillis() and friends ?

Thilo
  • 257,207
  • 101
  • 511
  • 656
1

java.util.Date does not have the concept of a timezone, it is just a thin wrapper around a GMT timestamp (if used correctly). It only may seem otherwise because its toString() method and some other legacy methods of the class implicitly use the system default timezone.

Calendar is only needed for date calculations, so you should not have to use it at all. All you need is to use SimpleDateFormat with the correct timezone to convert (format/parse) between Date instances (which do not have a timezone) and String representations (which have one, possibly GMT).

Michael Borgwardt
  • 342,105
  • 78
  • 482
  • 720
0

There can be many use cases like - we don't need time zone - we don't need hours - we don't need minutes - we don't need milli seconds

In such cases we can just clear tall such fields which are causing trouble and are not required 

calendar.clear(Calendar.ZONE_OFFSET);
calendar.clear(Calendar.MILLISECOND);
calendar.clear(Calendar.HOUR);
calendar.clear(Calendar.MINUTE);

All such fields are listed here - this link might be usful

https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html

Ashish Shetkar
  • 1,414
  • 2
  • 18
  • 35
0

java.time

The Answer by Jon Skeet is correct but now outdated.

As he said, the old legacy date-time classes are a mess and should be avoided. The Joda-Time project is now in maintenance mode, with the team advising migration to java.time.

LocalDateTime

The LocalDateTime class represents a date and a time-of-day with a resolution of nanoseconds. This value is unattached to the timeline, without any concept of offset-from-UTC nor time zone.

As such it does not represent an actual moment but a potential moment. When you place it in the context of an offset or time zone, then you imbue the new value (a OffsetDateTime or ZonedDateTime) with meaning as it becomes a point on the timeline.

For example, 2016-12-25T00:00:00 is when Christmas begins this year. But that stroke of midnight happens first in the Pacific such as Auckland New Zealand, which is earlier than Christmas in Kolkata India. And Christmas begins even later in Paris France, still later in Montréal Québec. That is why Santa starts in the east and works westward with his deliveries.

LocalDateTime xmas2016 = LocalDateTime.of( 2016 , Month.DECEMBER , 25 , 0 , 0 ) ;

Zoned

While your Question is not clear, I suspect what you really need is date-time values in UTC. All your various inputs in various time zones should be normalized into UTC.

Programmers should think of UTC as the One True Time. Most of your business logic, logging, data storage, and data exchange should generally be done in UTC. I suggest you keep a second clock on your desk set to UTC.

The Instant class represents a moment on the time line in UTC with a resolution of nanoseconds. 

Instant instant = Instant.now();

When you need to see the wall-clock time for some offset-from-UTC, apply a ZoneOffset to get a OffsetDateTime object. To see the wall-clock time for some time zone, apply a ZoneId to get a ZonedDateTime. 

ZonedDateTime xmas2016Montréal = xmas2016.atZone( ZoneId.of( "America/Montreal" ) );

Both of these offset/zoned date-time objects can get you back to an Instant with a call to toInstant.

Instant instant = xmas2016Montréal.toInstant();  // Convert to UTC.

About java.time

The java.time framework is built into Java 8 and later. These classes supplant the troublesome old date-time classes such as java.util.Date, .Calendar, & java.text.SimpleDateFormat.

The Joda-Time project, now in maintenance mode, advises migration to java.time.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations.

Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP (see How to use…).

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.

Community
  • 1
  • 1
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
0

Have a look at Veyder-time. It is a simple and efficient framework for time and date manipulation, and has a natural representation of these objects. Veyder-time is completely free from all complications such as TimeZones, epochs, eras, different calendar systems and such.

With Veyder-time, creating time and date objects, without any time zone, is simple. Look at these examples:

Time now = Time.factory.now();
Time time = Time.factory.parse("2011-08-01 12:49:21.123");
lonerook
  • 99
  • 3