9

How can I get the current local wall clock time (in number of millis since 1 Jan 1970) in London? Since my application can run on a server in any location, I think I need to use a TimeZone of "Europe/London". I also need to take Daylight Savings into account i.e. the application should add an hour during the "summer".

I would prefer to use the standard java.util libraries.

Is this correct?

TimeZone tz = TimeZone.getTimeZone("Europe/London") ;
Calendar cal = Calendar.getInstance(tz);
return cal.getTime().getTime() + tz.getDSTSavings();

Thanks

Lance Roberts
  • 22,383
  • 32
  • 112
  • 130
dogbane
  • 266,786
  • 75
  • 396
  • 414
  • If you're writing a server, the common paradigm is always to use UTC time internally, then format it using a DateFormatter when displaying it in the UI. – Kylar Mar 29 '10 at 18:22
  • 2
    @Kylar: Using only UTC isn't specific to server applications but should be done by pretty much any application out there. – Joey Mar 29 '10 at 18:23
  • 1
    I wouldn't presume to know all the applications out there ;) – Kylar Mar 29 '10 at 18:24
  • 4
    I didn't know that people in London use wall clocks that show Unix timestamps. – Mark Byers Mar 29 '10 at 18:25
  • Call +44 871 789 3642. They'll tell you. (http://en.wikipedia.org/wiki/Speaking_clock#United_Kingdom) – Ben Zotto Mar 29 '10 at 18:35

3 Answers3

16

I'm not sure what this quantity represents, since the "number of millis since 1 Jan 1970" doesn't vary based on location or daylight saving. But, perhaps this calculation is useful to you:

TimeZone london = TimeZone.getTimeZone("Europe/London");
long now = System.currentTimeMillis();
return now + london.getOffset(now);

Most applications are better served using either UTC time or local time; this is really neither. You can get the UTC time and time in a particular zone like this:

Instant now = Instant.now(); /* UTC time */
ZonedDateTime local = now.atZone(ZoneId.of("Europe/London"));
erickson
  • 265,237
  • 58
  • 395
  • 493
5

Others have said that it may well not be a good idea to do this - I believe it depends on your situation, but using UTC is certainly something to consider.

However, I think you've missed something here: the number of seconds which have occurred since January 1st 1970 UTC (which is how the Unix epoch is always defined - and is actually the same as in London, as the offset on that date was 0) is obtainable with any of these expressions:

System.currentTimeMillis()
new Date().getTime()
Calendar.getInstance().getTime().getTime()

If you think about it, the number of milliseconds since that particular instant doesn't change depending on which time zone you're in.

Oh, and the normal suggestion - for a much better date and time API, see Joda Time.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Doesn't the UK use DST as well? In that case it differs from UTC, actually. – Joey Mar 29 '10 at 18:39
  • 1
    @Johannes Rössel: DST or not, the number of (milli)seconds elapsed since the epoch is unrelated to daylight saving time. If it's 6PM or 7PM does *NOT* change how many (milli)seconds elapsed since the epoch. Minutes aren't a fixed unit (you can have 59 or 61 seconds minutes), days aren't a fixed unit (you can have 23 or 25 hours day) but seconds and milliseconds are a fixed unit. This is precisely why you *always* should measure time in (milli)seconds and store dates/time in (milli)seconds since the epoch. And only do the conversion when displaying them to the end user. – SyntaxT3rr0r Mar 29 '10 at 19:56
3

To get the current time in London:

SimpleDateFormat f = new SimpleDateFormat("dd MMM yyyy HH:mm:ss z");
f.setTimeZone(TimeZone.getTimeZone("Europe/London"));
System.out.println(f.format(GregorianCalendar.getInstance().getTime()));
Marcus Leon
  • 55,199
  • 118
  • 297
  • 429