0

I wrote some code today in VB6 which would get me the number of milliseconds since 1/1/1970, so I could then send the value off to a java application which would parse that value like new Date(Long.parse(milliseconds)). I understand that the milliseconds the Date(Long) is looking for is the number of milliseconds since epoch in GMT. The machine I am running on is on CDT here in the US. When I get the toString value of the date parsed from the milliseconds, this is the value I get:

Tue Aug 11 15:40:50 CDT 2015

Is the CDT just there because the local machines timezone is CDT? I just think its a little weird that the constructor for Date would assume that a date derived from the milliseconds since epoch in GMT would implicitly be in the local machines timezone, rather than being offset (in this case) by -5 hours.

Mark W
  • 2,791
  • 1
  • 21
  • 44
  • 1
    Maybe im misunderstanding, but it seems a lot more likely that your VB6 code is giving you the time of your current timezone – JShell Aug 11 '15 at 20:58
  • 1
    The millisecond value is the same all over the world and in all time zones. The millisecond value is not "in" UTC or GMT. It has no timezone, and it is the same in all timezones. – AgilePro Nov 09 '22 at 05:06
  • Yes, the `Date` class is confusing. This is far from the only point. Fortunately it is also outdated. Instead use `Instant` from [java.time, the modern Java date and time API](https://docs.oracle.com/javase/tutorial/datetime/). And by the way, rather than passing milliseconds from VB6, pass [ISO 8601 format](https://en.wikipedia.org/wiki/ISO_8601), for example `2015-08-11T20:40:50Z` (the trailing `Z` means UTC). – Ole V.V. Nov 09 '22 at 07:07
  • The string from `toString()` contains an *ambiguous* time zone abbreviation. CDT may be for Australian Central Daylight Time, North American Central Daylight Time, Cuba Daylight Time or Chatham Daylight Time. – Ole V.V. Nov 09 '22 at 08:56

4 Answers4

3

Is the CDT just there because the local machines timezone is CDT?

The timezone for display purposes is based on the default time zone.

The millis in the Date is relative to epoch and it doesn't have a time zone of its own.

It is taken since 00:00 1/1/1970 GMT or if you prefer 17:00 12/31/1969 CDT.

would implicitly be in the local machines timezone

The use of the local time zone is for display purposes only. Use another time zone or serialize the Date and send it to a machine in another timezone and it will use the local timezone again.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • I'm trying to determine if im doing anything wrong with the VB6 side of things. I am miserable at DateTime logic :(. In that application im simply getting the number of milliseconds since epoch, then applying a timezone offset, and sending off value to the java application. If I don't apply the timezone offset on the VB6 side, the value I get is always off by actual local timezone offset. Am I correct in applying the offset VB6 side like I am? It seems to give me the correct value... Both machines are in the same TZ btw. – Mark W Aug 11 '15 at 21:04
  • "then applying a timezone offset, " The number of millis since epoch is all you need, there is no time zone offset to apply. Epoch is the same all around the world. – Peter Lawrey Aug 11 '15 at 21:11
  • But when I do that, the Long value that is calculated happened 5 hours in the past.... I've gotta be doing something wrong. – Mark W Aug 11 '15 at 21:12
  • @MarkW My guess is you are doing `00:00 1/1/1970 CDT` which is why you need to apply a timezone offset to get `00:00 1/1/1970 GMT` – Peter Lawrey Aug 11 '15 at 21:12
  • that's probably it... Thanks Peter! – Mark W Aug 11 '15 at 21:13
  • @MarkW Try `17:00 12/31/1969 CDT.` as epoch instead ;) – Peter Lawrey Aug 11 '15 at 21:19
  • 1
    What I ended up doing was getting the TIME_ZONE_INFORMATION structure from a win api call, then wrote a function to determine if the current time is in US Daylight time or Standard Time. With that info I could either offset it by the bias, or the bias + the daylight bias. That worked out without me having to do any weirdness. Tested with DST and standard times, and all is well. Thanks again Peter! – Mark W Aug 13 '15 at 16:01
3

You're correct it's showing CDT in the toString() because your locale indicates that is the correct timezone for you. The Date object itself doesn't care about timezones and is a glorified wrapper around the Unix epoch in milliseconds. Generally you should use toString() for debugging purposes, and use a date formatter to actually display dates to the user (optionally specifying an explicit timezone instead of the one specified by the user's locale).

The Javadoc for Date.toString() only specifies the format of the string, it doesn't actually say anything about which timezone is used. I wouldn't rely on toString() always returning the default Locale in every implementation of Java.

Samuel
  • 16,923
  • 6
  • 62
  • 75
0

You can use a custom representation of a date by using the correct format

Read this post, it might help you Change date format in a Java string

Community
  • 1
  • 1
PekosoG
  • 246
  • 3
  • 9
0

The number of milliseconds since epoch began is NOT in the timezone known as UTC. It is not in any time zone. The epoch value is the same in ALL time zones. That epoch millisecond value is the same in London as it is in New York or San Francisco for that instant in time.

The Date function always uses the current default time zone if you don't set one. So for you, yes, the local machines timezone is CDT. Again, the epoch value in CDT is exactly the same as everywhere else on the planet, so there is no real reason to pick UTC when your machine thinks it is in central time.

AgilePro
  • 5,588
  • 4
  • 33
  • 56