CODEWITHSUNDEEP
javadatetimelocaldatetime
zsf
zsf

Reputation: 45

Same unix timestamp in two regions which are in the same timezone has different result

This code convert datetime to unix timestamp, but I have different result when I check the result in Mexico_City and Chicago, which are in the same timezone.

The result is :

Friday April 03, 2020 08:45:18 (am) in time zone America/Mexico City (CST) and

Friday April 03, 2020 09:45:18 (am) in time zone America/Chicago (CDT)

How to solve this problem?

https://www.epochconverter.com/timezones?q=1585925118&tz=America%2FMexico_City https://www.epochconverter.com/timezones?q=1585925118&tz=America%2FChicago

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")
LocalDateTime dateTime = LocalDateTime.parse(2020-04-03 09:45:18, formatter);
ZoneId zoneId = ZoneId.of("CST", ZoneId.SHORT_IDS)
ZoneOffset zoneOffset = zoneId.getRules.getOffset(LocalDateTime.now)
ldt.toInstant(ZoneOffset.of(String.valueOf(zoneOffset))).toEpochMilli //1585925118000

Upvotes: 2

Views: 839

Answers (1)

Anonymous
Anonymous

Reputation: 86280

Not the same time zone

Your results say it:

Friday April 03, 2020 08:45:18 (am) in time zone America/Mexico City (CST) and

Friday April 03, 2020 09:45:18 (am) in time zone America/Chicago (CDT)

Two time zones are mentioned, not one: America/Mexico City and America/Chicago. Both time zones have the same standard offset from UTC, -06:00, and both use summer time (Daylight Saving Time, DST), yet they are different time zones.

Your results are correct

This year (2020) summer time began on March 8 in America/Chicago. So on your example date, April 3, summer time was observed. Summer time was not observed in America/Mexico_City on this day. There summer time did not begin until April 5. This difference explains why the time was 8:45 in Mexico and simultaneously was 9:45 in Chicago. Use the links at the bottom for verifying the dates of the summer time transitions in the two time zones.

What is a time zone?

A time zone, as the name says, is a zone on Earth, but the concept also comprises the historic, present and known future offsets from UTC observed by the people in that zone.

Every time zone has a unique ID in the region/city format that is also used in the output from the Epoch Converter that you have used.

CST is not a time zone. CST is an ambiguous abbreviation. As mentioned in the comment it may refer to Central Standard Time, Cuba Standard Time or China Standard Time. You intended Central Standard Time, but even that is ambiguous: it may refer to North American Central Standard Time or Australian Central Standard Time. And while North American Central Standard Time is unique, unambiguous, it is not a time zone. It is the time used in America/Chicago and America/Winnipeg time zones (and more time zones) during the relatively few months of the year where standard time is observed. The rest of the year the mentioned time zones use Central Daylight Time instead. But yes, CST is also used in Mexico City for some of the year.

In Java ZoneId.of("CST", ZoneId.SHORT_IDS) gives you America/Chicago time zone because SHORT_IDS is defined to do that. This definition is there for one purpose only: to give you a behaviour that is compatible with what the now long outdated TimeZone class would have given you. Unless CST is used in your program for historic reasons and cannot (easily) be abandoned, you should neither use this nor SHORT_IDS. Use ZoneId.of("America/Chicago") if this is the time zone you want.

Links

Upvotes: 0

Related Questions