I have been studying several topics that address the question of the validity of Daylight Saving Time [DST] by calling certain Clock Properties and how it can positively or negatively interfere with the results of some operations.
But what I don't finish understanding is how 'Instant' decides this information.
Since there is no Clock Property that references a particular city or place that can be programmatically defined -and 'Instant' always knows accurately the Time zone and an eventual DST- I estimate that this information about the Time zone and DSTs take as reference internal time settings manually defined by the User on the Android device or from Sensor... but I am not very clear how this happens.
But not necessarily an entire Time zone band adopts DST evenly throughout the whole track. According to individual provisions, there will be countries within this range that adopt the DST - starting and ending on different days and hours- and there will be countries (or States) that do not adopt it.
This means that so that 'Instant' can elucidate DST [ ̶v̶i̶g̶e̶n̶c̶y̶] validity, somehow it is taking from device not only the reference of the Timezone defined, but also the place of the device... which means the same 'Instant' defined programmatically will have different results according to the Timezone and the Location of the User.... and even more: the validity or not of DST will be specifically linked to this Location!
My questions are:
Where do 'Instant' get the current Timezone? Is this done based on the device location sensor and later calculated? Or such information comes from UI?
Where did 'Instant' get the User Location? Is this done by the device location sensor? Or such information comes from UI?
To decide DST validity, does AI2 use any specific API or any specific NTP Server [Network Time Protocol]?
How your Android knows its time zone and whether DST is in use at the moment or not using using the Clock.
This show I am in the Central Time Zone and DST offset is 0 meaning standard time is in effect. Each device will provide that information for it's current location and what Google has in its record database. See the Time zone rules to understand how it does this.
Difficult to automatically get whether DST is in place on the selected city without going online to find out, but this example should show you the correct time for any city, and allow you to see the time if DST is in place.
@TIMAI2 If you are saying it is difficult, it must be really difficult.
Please, what is the meaning of this?
Please clarify me » With these Blocks no matter which option is selected in CheckBox. Both Labels will be visible, making information confused...
» Is Label2 the 'standard' timezone of the selected location?
» What is the meaning of the Label3? Does it show you what timezone would be when the place is with DST in Force, even if the DST validity is not applicable for this location?
It was not very clear to me the logic of this programming... sorry...
Very interesting to read this text. Really clarified many things... tks.
Despite the enlightening text, it is not clear if the LocationSensor has participation in this.
It is understood that device will provides that information for it's current location, but although the origin of such data will respect the timezone that was set in the device's date and time settings, is not specified in the text if the LocationSensor is read to improve this information.
More modern devices have the possibility of setting the 'Region' beyond the timezone... but older devices does not have this option... which leads to think that the LocationSensor is rather consulted to define DST validity for timezones that house different countries.
If you get to know about some text that clarifies this information, please send me.
Time is a quite arbitrary concept (along with time zones and standard time zones and daylight savings time zones).
Prior to the 19th century or there about, a day started when it was light enough to see and when one felt tired and could no longer see the sun. Man got tired, went to sleep (and hoped they would wake up again). The location of the Terminator (sunrise sunset line and astronomical mechanics decided when you should be awake and feed the cows and pigs. ( With App Inventor, see the Terminator tutorial )
The most arbitrary of concepts might be DST (see the articles in How Are Time Zones Decided? ).
Where and when DST is observed is entirely serendipity. If you want to know where the earth in anyplace is in sunlight or not (assuming no clouds or smog), determine the sun's position.
The LocationSensor and the Clock (System Time) work together to attempt to identify what time zone an Android is in and provide information about whether the device is using standard or daylight savings time. When you are connected to a mobile network, the date and time will be set automatically. This may mean that the indication you get for DST may be determined by where your phone service provider is located, not your device location.
Where does Android get time from?
A time signal from a network time server ( provided by your phone service carrier, not necessarily Google) might be used to set the Android device's system clock if automatic time detection is supported on the device and the time detector service is configured to use it. Android uses the network time origin as the primary automatic time detection origin by default.
Reading a lot of articles about DST I believe there isn't any 'official' source for knowing when DST is locally in force. Your phone makes its best efforts and web sites try to collect the best information available and frequently that information is not up to date. So why do we have a discussion about whether the information about the timeanddate. com information is valid?
App Inventor uses the device's system time zone (typically configured by the user via the Settings app). It is not computed based on the user location. If you compile an app that contains just a Clock you will see it will not have location permissions required.
