0

Strange thing. I have SQLite Android database with dates kept as long values. I read them as Date objects ex.:

new Date (cursor.getLong(4))

Next when displaying I convert Date objects to String with toString() method. However sometimes the displayed String contains CET and sometimes CEST.

Sure the fact that time zone info is added is not surprising. What is surprising the fact that at the same device, with values get from database in the same time, being long values thus not containing any zone time information, java sometimes add CET and sometimes CEST. Why there is such a difference?

The only difference is that long value which gives in result CEST has time equal to 00:00:00 while those giving in result CET has time different.

Any idea?

user2707175
  • 1,133
  • 2
  • 17
  • 44
  • I think it depends on the time of the year a particular date is falling into. Please mention the two dates which result in different timezones. –  Oct 30 '13 at 23:18
  • I'm doing conversion at the same time - one conversion just after the second one. And AFAIU date as long is kept without any zone information, if stored from java program zone is taken into consideration when converting date to long (GMT time kept as long value), if from other program it depends, how it works. – user2707175 Oct 30 '13 at 23:21
  • A `Date` object represents number of milliseconds from an instant called "the epoch". Even when a `Date` object is converted to `long`, zone information is not used. –  Oct 30 '13 at 23:25
  • Ok so why when converting long to Date and next to String I get two different time zones? – user2707175 Oct 30 '13 at 23:30
  • Take a look at this answer - http://stackoverflow.com/questions/2092340/strange-problem-with-timezone-calendar-and-simpledateformat –  Oct 30 '13 at 23:31

1 Answers1

2

The values themselves are totally time-zone agnostic, but your device is not. Your device has two time zones, CET and CEST, as part of its locale. Dates that fall during the time when daylight savings time was/is/will be active are given in CEST, other dates are reported as CET.

If you set your device to a locale that doesn't observe daylight savings time, only that one time zone will be reported.

To see why this makes sense, consider if you asked me what time it is now, and I said "13:35 CEST." Inasmuch as CEST is UTC+2, I'm correct, but you'd likely be confused. Because CEST isn't used at this time of year, it only makes sense to gives times in CET. That's why the timezone varies depending on the date.

blahdiblah
  • 33,069
  • 21
  • 98
  • 152
  • Now that's clear although quite surpising at first glance. I'm just wondering about one thing. If I have (new Date()).getTime() in my code (which gives me the current date in miliseconds let's assume it's 2013.10.31 00:45), next I store this information in database and someone else being in different time zone will take this long value, convert to Date object and next to String. Will he/she get the same string 2013.10.31 00:45 CET or will the system take into consideration different time zone and will display ex. 2013.10.31 02:45 Zone+2 (whatever it is)? Or perhaps 2013.10.31 00:45 Zone+2? – user2707175 Oct 30 '13 at 23:55
  • Concluding if Date object converted to milliseconds give always no of miliseconds since "the epoch" to the current GMT time or local time? – user2707175 Oct 30 '13 at 23:56
  • @user2707175 Someone else in a different locale will get a different string when they make a new Date from that long. – blahdiblah Oct 30 '13 at 23:58
  • @user2707175 The number of seconds since the epoch is the same regardless of time zone. Imagine if the epoch were "when you submitted the comment I'm replying to." No matter what timezone someone's in, they're still going to see the time it was submitted as "3 mins ago" (if they look right now). – blahdiblah Oct 31 '13 at 00:01
  • @ blahdiblah thank for answer but it's not still clear for me - does Date keep always no of ms according to GMT zone or to local zone? – user2707175 Oct 31 '13 at 09:04
  • @user2707175 Date always keeps the number of ms since a specific point in time which happens to be 00:00 1 January 1970 UTC (which was 01:00 1 January 1970 CET). – blahdiblah Oct 31 '13 at 16:43