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
@>-->---
I would not classify this as a bug in App Inventor. All an Instant is in App Inventor--at least on Android--is a java.util.GregorianCalendar, which wraps a Java TimeZone object, and all of that is implemented by the Android runtime provided by your phone. If the APIs are returning bad values, it either is a bug in Android, or it's an issue in the tzdata database bundled by your phone's manufacturer.
@ewpatton An issue in the tzdata database bundled by my phone's manufacturer is discarded. The problem happens in all the devices... The question made to @ABG and his answer here corroborate this.
In the city where @ABG device resides the DST entered into force on Sunday, March 9, 2025, 02:00:00 when clocks were turned forward 1 Hour. And how you can see the Gregorian Calendar Object from his device points out that at 23:00 on March 9 there was standard time and that the DST validity only started at the next hour at 00:00 March 10.
In fact, it is a systematic Android bug, on the Gregorian Calendar object, which will always display the entry into force of DST at 00:00 of the day, no matter when DST was really started.
Obviously, this disparity generates numerous errors in commands and time calculation functions within AI2, with results that challenge the laws of mathematics and about which I could show you several examples.
At no time did I suggest that this could be an AI2 bug.
When I mentioned that "I will like to know if for MIT it is a priority to solve this" and asked if "i should detail the issue in 'bugs and other issues" I just mentioned this category because, in fact, I found an Android bug that has completely damaged the results of an AI2 programming to identify the DST periods of any city in the world... and I don't know what to do with this.
I have no idea how to notify an Android bug for the Android team... and, sincerely, I expected someone, especially you, could help me with this. It will have much more force if MIT notify the bug for Android team but if, at least, you or someone could guide me about the following steps when a bug is found on an Android Object, I would be grateful... because it is a detail that made a complex AI2 program of DST tracking that you can see, you has access to my projects and you can find that such bug compromises all the results when the timezone of the device is set for a City in which the DST comes into force no at 00:00hs but a little later than that.
My need to establish DST validity periods in the user's city is just a small detail, within a much larger project that needs this information accurately to proceed to other calculations and it is inadmissible that this information contains errors. Therefore, I still have the hope that the bug will be identified, corrected and so I can take my AI2 project forward, because I have worked a lot on it as well to give up it.
Can you help me notify the bug to the Android Team? I am willing to provide all the relevant details for its clear identification, if applicable.
Lito
@>-->---
Here you go, but first do a search there, if that bug already has been reported
https://source.android.com/docs/setup/contribute/report-bugs
Taifun
Hi Lito,
I remember seeing that reference too — it might have been part of the official Epoch docs or a deep-dive community post. I’ll check my bookmarks and let you know if I find it. Meanwhile, maybe try searching with terms like “Epoch config breakdown” or “Epoch item properties list” in quotes. Hope it turns up soon!
keep in mind that tm sim registration is necessery. Must regutser your tm sim card online
