Once, investigating the forum, I found a very consistent reference with a complete description of each of the Epoch items or properties. I need this now, but I can't find where and how I saved this, I can't even find it again in the forum, even trying several search keys.
Please, does anyone have this information in hand?
TIA 
Lito
@>-->---
you can convert this to a string, using JOIN block with a empty string. then parse this result.
You did a Do it on the Now method of the clock component
Taifun
there is also this (click on the image to follow the "here" link):
Here are some resources that may or may not be useful:
Some of the information you highlighted is in the GregorianCalendar object and the remainder is in the ZoneInfo object. The ZoneInfo object is a representation of the data for a particular time zone from the tz database included in your Android device.
It is also worth noting that Instants are a leaky abstraction in App Inventor since they aren't particularly well defined on our end. For example, the string version is different between the Android and iOS versions due to them being backed by different objects on the two platforms. If you're looking to parse this information from the string representation don't expect it to necessarily work across platforms and even different versions of the same platform.
(added to FAQ)
@ABG Your device works under the timezone America/New York, right?
Can I ask you to check the result of a Companion 'Do It' over a Block?
I am identifying an incongruity in the Epoch pattern, but I need to make sure this also appears on devices that are positively located in NY.
I am not 100% sure that when I change the timezone on my device in Brazil, this reproduces identical conditions and generates the same Epoch as a local device that received all the inherent updates to its 'real' timezone.
(Epoch = String of the Gregorian Calendar object in Java, provided by AI2 Instant in Clock Tools)
TIA
Lito
@>-->---
Which block?
Clock1.Now()?
This Block, please...
On my device, setting the timezone for NY, NY the Epoch indicates that on March 9, 2025 at 23:00h [11pm] DST had not yet started...
But the DST came into force from 00:00h [12AM] on March 10, 2025
By other references that I have judged reliable over the years, it seems that in NY the DST has come into force at 2:00am on March 9, 2025 and not when the Epoch on my device indicates...
Please, check the same pair of 'Do It' from the Draggable Block in your Companion, to see if the Epoch indicates the same result.
Lito
@>-->---
OK @ABG Thanks
This means that:
The Epoch I get on my device by using a NY timezone is consistent with the Epoch obtained on a local device, except for a subtle difference*****
In both cases it is indicating that the DST came into force in NY 22 hours later, pointing to 00:00 of the next day [March 10, 2025] when we actually know that in NY the DST entered into force on March 9 at 02:00
I estimate that -for all purposes- your device adjusted the time at the beginning of Sunday, March 9 at 02:00, when clocks were turned forward 1 hour to 03:00hs... and that this would never be done at the beginning of Monday, at the day 10th.
However, such adjustment may have been determined not by Android's Epoch... but by the telephone network of which your device is part -if the automatic Date and Time settings have been previously setted-
Which allows to conclude that the Epoch generated in AI2 indicating that such a change was made on March 10 at 00:00 is wrong
This same rounding pattern for 00:00 to the next day that I have found it for several timezones around the world -in specific circumstances- is always the same...
I would ask other people to check these changes in their devices, but as long as the results when changing the timezone in my device are consistent, it seems to me that this is now unnecessary...
The question that does not want to silence comes from the following:
Since we know that the resulting string in Epoch is a composition of the GregorianCalendar Object plus Zoneinfo Object, according to data representation of a specific timezone that responds to TZ database updates included in the Android device -which follows the IANA Standards » the authority that determines the start and end of DST for each region and timezone worldwide-
The Epoch generated by the AI2 Clock1.MakeInstantFromParts Block is the pure string returned by these Java Objects, provided by Android?
Or this string is modified when AI2 makes up the Epoch to be used by MakeInstantFromParts?
In the first case, this means that the error pattern found as to the beginnings and ends of DST in some timezones would be originated on the string provided by Android...
Already in the second case, this would mean that the error pattern found would be originated in the composition of the Epoch made by AI2 when is generated the Instant for the Block Clock1.MakeInstantFromParts
***** Please note that the subtle difference between the Epoch generated on my device and in yours is in 'transitions'... which in my case points to = 235 and in your case points to = 236
Lito
@>-->---
By now, I have blissfully forgotten which day the DST transition occurred.
I do recall the havoc it wrought to the web site listing my local Over The Air TV schedule for the week.
I had to tweak my web site profile to realign their listings for a day or two.
@ewpatton Thank you so much for all the information. All links were very useful to me.
Is there any intention from MIT to review the criteria that define Instant?
I found a persistent incongruity, which is systematically repeated on the property that defines the Validity of DST.
» Regardless of the timezone relating to any country to make the changes to DST start or end at different times of 00:00 hours, Epoch will always display these changes at 00:00.
This means that when DST officially starts or ends at 00:00hs in a given timezone, Epoch String will correctly reflect changes, alternating to DST_OFFSET=0 or DST_OFFSET=3600000 at the correct moments of each transition... but if eventually official changes to this timezone occur after 00:00 hours (such as 02:00 or 03:00 hours) Epoch will only reflect these changes at 00:00 hours in the next day.
This incongruity, in addition to being the nightmare of any programmer, produces incorrect results in virtually every tool of Clock. There is no way to circumvent this problem programatically, because no Property of the GregorianCalendar Object indicates the time of DST transitions from the ongoing timezone. Only the value of DST_OFFSET in the String allows us to decide whether the DST is in force or not on the Instant being parsed.
Therefore, I would like to know if for MIT it is a priority to solve this and if I should detail the issue in 'Bugs and Other issues' or where it is most convenient.
Lito
@>-->---
OK. After 8 days of silence I believe that the best thing to do is interpret this silence as: "No. MIT is not interested in solving this issue with Instant"... and considering uselessly detail this problem in 'Bugs and Other Issues'
TKS
Lito
@>-->---
