When I run the below line,
System.out.println(java.util.TimeZone.getDefault());
I got the following output.
sun.util.calendar.ZoneInfo[id="Asia/Calcutta",
offset=19800000,
dstSavings=0,
useDaylight=false,
transitions=6,
lastRule=null]
and
System.out.println(Locale.getDefault()); gives
`en_US`
My doubt is
How could the Locale be en_US, When My Zone id is Asia/Calcutta?
in the first output, I haven't understood what are offset, dstSavings, useDaylight, transitions and rules ?
Could anybody help in understanding these.
Thanks in advance...
Locale has nothing to do with TimeZone, you can setup your computer in French in Australia if you want... you won't need France TimeZone for that.
To know more about TimeZone, you should read theses :
TimeZone
What is a TimeZone
The class that actualy give you the toString() : ZoneInfo
useDaylightTime
public abstract boolean useDaylightTime()
Queries if this time zone uses daylight savings time.
What is Daylight Saving Time.
getDSTSavings
public int getDSTSavings()
Returns the amount of time to be added to local standard time to get local wall clock time.
So this is the difference between the UTC + TimeZone + (DSTSavings - 0 or 1 hour). If you are currently in DST savings mode, will return 1 hour.
rules
Rules mean the date when the DST is active and date when it is no more. More info SimpleTimeZone.
transitions
This array describes transitions of GMT offsets of this time zone, including both raw offset changes and daylight saving time changes. A long integer consists of four bit fields.
The most significant 52-bit field represents transition time in
milliseconds from Gregorian January 1 1970, 00:00:00 GMT.
The next 4-bit field is reserved and must be 0.
The next 4-bit field is an index value to offsets[] for the amount of daylight saving at the transition. If this value is zero, it means
that no daylight saving, not the index value zero.
The least significant 4-bit field is an index value to offsets[] for total GMT offset at the transition.
If this time zone doesn't observe daylight saving time and has never
changed any GMT offsets in the past, this value is null.
Check this question to understand how Locale.getDefault() actually works.
As for your output for System.out.println(java.util.TimeZone.getDefault());
DST Savings: The base implementation returns 3600000 (1 hour) for
time zones that use daylight savings time and 0 for timezones that
do not
Offset: This is the offset of your timezone w.r.t GMT. For India,
it is 5hr30min which is 19800000 ms
UseDaylight: This shows that there is no daylight adjustment for
this timezone .
Transitions: This refers to the daylight saving time transitions
of a timezone.
LastRule: Returns a SimpleTimeZone object representing the last GMT
offset and DST schedule or null if this time zone doesn't observe
DST.
Hope this helps.
Related
I'm trying to retrieve the Unix timestamp for midnight of the current day. Timezone not relevant.
I'm looking for something like: 1625716800
Every tutorial I've found is for retrieving formatted strings, such as: "Thu Jul 08 2021 04:00:00"
It needs to be midnight. Not just the current seconds or milliseconds.
Any advice is appreciated.
Many thanks.
I'm trying to retrieve the Unix timestamp for midnight of the current day. Timezone not relevant.
This is impossible. The concept of 'a day' does not exist in unix timestamp space. This space just ticks away 1 unit every millisecond that passes, since some universally defined epoch (in unix space, that epoch occurred at that instant in time when someone in greenwich, UK, would tell you that right this very moment it is jan 1st, 1970, midnight). There's no such thing as days in this system, no such thing as dates. Just 'millis since the epoch', and that's all you get.
If you want concepts like 'day', 'month', or 'hour', you simply can't do that in this space; these are human concepts and you can't know what the right answer is unless you involve a political unit which decides how to translate such an epoch to an actual 'it is this date in this month in this year, this hour, this minute, etc'. Political units have timezones, daylight savings times, and more - and they all effect when 'midnight' might be.
When it is midnight in Europe/Amsterdam, it's not midnight in Asia/Singapore. Hopefully this helps you understand that the concept 'at midnight' doesn't make sense unless you add to this some notion of 'where'. Could be 'whereever the system thinks it is', (e.g. platform default timezone), could be at the essentially fictional UTC timezone, could be at some specific timezone, could be at a user-specified timezone. But it's gotta be in some timezone.
Furthermore, 'current day' is ambiguous. That, too, just isn't a thing unless timezones are involved. Current day where? Amsterdam? Singapore? Los Angeles? As I said, millis-since-epoch has no idea what 'day' means. It just knows when the epoch was and what a millisecond is, and it knows nothing more.
In fact, 'midnight' doesn't work at all. It may not exist. Most places will advance the clock by an hour, if they do so at all, at 2 AM, but not all zones do. Thus, midnight may simply be a time that never was. One moment in time it is 23:59:59 on March 22nd. The next moment in time, it is 01:00:00 on March 23rd. Presumably what you actually mean is 'start of day', as in, the very first instant in time that can be called 'the date is now X' in the decided time zone. Which usually is 00:00:00 but there are extremely exotic cases where it's not. The problem is, 'extremely exotic' is not equal to 'never happens'.
Let's assume the zone relevant for 'current day' and 'at the start of this day' are all from the same zone, then what you're looking for:
ZoneId zone = ....;
ZonedDateTime zdt = ZonedDateTime.now(zone);
zdt = zdt.toLocalDate().atStartOfDay(zone);
long v = zdt.toInstant().toEpochMilli();
Where zone can be many things. For example, ZoneOffset.UTC, or ZoneId.systemDefault(), or ZoneId.of("Europe/Amsterdam") for example.
Let's give it a whirl with ZoneOffset.UTC:
ZoneId zone = ZoneOffset.UTC;
ZonedDateTime zdt = ZonedDateTime.now(zone);
zdt = zdt.toLocalDate().atStartOfDay(zone);
long v = zdt.toInstant().toEpochMilli();
System.out.println(v);
See this code run live at IdeOne.com:
1625702400000
import java.util.Calendar;
class test{
public static void main(String[] args) {
Calendar cal = Calendar.getInstance();
cal.set(cal.get(Calendar.YEAR), cal.get(Calendar.MONTH), cal.get(Calendar.DATE), 0, 0, 0);
System.out.println(cal.getTimeInMillis());
}
}
I am testing my app in different timezones. I manually changed my physical phone's timezone to be London UK which is GMT+00:00
However, when I print the timezone using myCalendar.getTimeZone().getDisplayName(true, TimeZone.SHORT), it prints:
GMT+01:00
Why's it adding an hour to the offset?
EDIT:
By setting the getDisplayName's first parameter to false, I get the correct GMT+00:00 but I am not sure why I should be setting it to false. As far as I know, London UK is always GMT+00:00? Am I wrong?
As far as I know, London UK is always GMT+00:00? Am I wrong?
Yes, you are wrong. The United Kingdom observes Greenwich Mean Time (GMT) in the winter, and observes daylight saving time, locally called "British Summer Time" (BST), in the summer.
GMT = UTC+00:00
BST = UTC+01:00
Reference here, and here.
According to the API, getDisplayName()'s first parameter indicates if daylight savings should be used.
Returns a name in the specified style of this TimeZone suitable for
presentation to the user in the default locale. If the specified
daylight is true, a Daylight Saving Time name is returned (even if
this TimeZone doesn't observe Daylight Saving Time). Otherwise, a
Standard Time name is returned.
This is probably why the time is an hour ahead with that value set to true, as a value of true will cause a daylight savings hour even if it isn't observed in that timezone.
Given a timezone (America/New_York), how do I go about getting the UTC offset?
I have tried using java.util.TimeZone but had no luck. I am fine with using Joda Time as well if the solution is viable in that.
The offset for a particular time zone can vary based on the current time because of daylight savings, etc. UTC doesn't have daylight savings, but "America/New_York" will change offsets with the daylight savings switch. Therefore, the offset is a function of both the current time and the timezone. The answers here give some examples of how to get the current offset:
Java TimeZone offset
Note: Current offset depends on
raw tz-offset
day-savings time (DST) for a CURRENT moment.
This is well described in near answer.
Useful snippets:
TimeZone.getTimeZone("Europe/Kiev").getOffset(Instant.now().toEpochMilli());
will give you integer offset in millisecons
String.format("%tz", Instant.now().atZone(ZoneId.of("Europe/Kiev")));
will give you a standardized string representation like "+0300"
I never would believe that this could amount to being such a hassle. I am trying to make a clock that always displays the local time in specific timezones.
My laptop is currently set in GMT0 timezone (UK).
I want to get the milliseconds of the timezone "Europe/Stockholm".
So let's say it's 17:00 here in the UK I would like to get the milliseconds corresponding to 18:00 which would be the Swedish time.
The time in milliseconds as used by Date is independent of the time zone. Only when you print (or parse) a time, you use a DateFormat that is localized, so it ensures you get the time in the specific timezone.
When time is represented as milliseconds (or seconds or nanoseconds, etc), that is almost always milliseconds since some epoch. In the case of unix and java, this is midnight Jan 1, 1970 UTC.
Time zones are generally arranged as a round number of hours relative to UTC. In certain time zones it's not a round hour but 30 minutes, 15 minutes or 45 minutes from a round hour.
Nevertheless, for any time unit below a minute, all those time zones match UTC exactly.
Therefore, whatever the current second or millisecond is in Sweden, it is the same as it is, for example, in Nepal, whose time zone is 5:45 minutes from UTC.
When you work with an object that allows you to retrieve the separate fields of the given time, the milliseconds field will usually reflect just the number of milliseconds since the beginning of the current second, not the number of milliseconds since midnight. Therefore it will never be more than 999, and it will be the same the world over.
After reading the answers here and discovering another route, this is what finally worked for me.
DateTime curDateTime = new DateTime();
int offset = DateTimeZone.forID("Europe/Stockholm").getOffset(curDateTime.getMillis());
long milli = (curDateTime.getMillis()+offset);
I have a requirement where I only have GMT time without any offset, example 15:00:00, my requirement is to find out what timezone this GMT time belongs to, I have tried to solve it by using my local time and converting it to GMT time and doing some comparison but I don't think that it might be the right way to do it.
Assuming that the time is definitely offset from GMT, you should be able to produce a GMT timestamp using the following, and then compare the two. Your resulting answer, converted back to hours, should be the offset, which you can then lookup.
new Date().getTime();
Note that this doesn't take into account daylight savings/summer time etc, and assumes that the time given is right now, and can therefore be compared to the current GMT time. Specifically, remember that a timezone can fluctuate by a couple of hours if, like the UK and Australia, their summer/winter periods are reversed, so a +11 hour time zone offset may actually be +10 or +12 at any given point in time. And some countries don't use DST at all, even in the same time zone.
Note also that the entire point of time zone offsets and use of a centralised time (eg UTC) is to avoid the above confusion. By definition, you're doing things the long way round and introducing levels of uncertainty.
You may therefore have one country in the northern hemisphere varying +/- 1 hour, one in the southern varying -/+ 1 hour, and one near the equator using the same time constantly... and you'd have no idea which ones are meant to be in that time zone. You can find the offset, but that's about it.