Re: [tz] Welcome to the "tz" mailing list
Hello team, According to the latest 2020a tz update: Canada's Yukon, represented by America/Whitehorse and America/Dawson, advanced to -07 year-round, beginning with its spring-forward transition on 2020-03-08, and will not fall back on 2020-11-01. We have written a test cases like below for canada yukon timezone. We imported new 2020a tz into our environment. Our code seems correct but test cases are failing. So we found that there is wrong in Iana tz side. Please check and correct us. This is the below code we have written. @Test public void doesNotFallBackToMinus8InDawsonNovember2020() { DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)-------> on 2nd nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> on 1 st nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); long offsetOnDay = timezone.getOffset(day.getMillis()); int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); assertEquals(hoursOnDay, dayAfterHours); -------> here we are getting error: java.lang.AssertionError: expected:<-7> but was:<-8> } The above test case according to your update (will not fall back on 2020-11-01) is correct. But test case is failing. Could you please clarify us that is there anything wrong from IANA tz. If not how can i write my test case according to that? Regards, Sundar On Wed, May 20, 2020 at 3:51 PM <tz-request@iana.org> wrote:
Welcome to the tz@iana.org mailing list!
---
NOTE WELL
Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to:
* The IETF plenary session * The IESG, or any member thereof on behalf of the IESG * Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices * Any IETF working group or portion thereof * Any Birds of a Feather (BOF) session * The IAB or any member thereof on behalf of the IAB * The RFC Editor or the Internet-Drafts function * All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879).
Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice.
Please consult RFC 5378 and RFC 3979 for details.
A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements.
A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.
---
To post to this list, send your email to:
tz@iana.org
General information about the mailing list is at:
https://mm.icann.org/mailman/listinfo/tz
If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at:
https://mm.icann.org/mailman/options/tz/gkssarma59%40gmail.com
You can also make such adjustments via email by sending a message to:
tz-request@iana.org
with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions.
You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is:
Gks59@smu
Normally, Mailman will remind you of your iana.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you.
On 2020-05-20 05:32, Sundar Sarma wrote:
According to the latest 2020a tz update: Canada's Yukon, represented by America/Whitehorse and America/Dawson, advanced to -07 year-round, beginning with its spring-forward transition on 2020-03-08, and will not fall back on 2020-11-01. We have written a test cases like below for canada yukon timezone. We imported new 2020a tz into our environment. Our code seems correct but test cases are failing. So we found that there is wrong in Iana tz side. Please check and correct us. This is the below code we have written. @Test public void doesNotFallBackToMinus8InDawsonNovember2020() { DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)-------> on 2nd nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> on 1 st nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); long offsetOnDay = timezone.getOffset(day.getMillis()); int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); assertEquals(hoursOnDay, dayAfterHours); -------> here we are getting error: java.lang.AssertionError: expected:<-7> but was:<-8> } The above test case according to your update (will not fall back on 2020-11-01) is correct. But test case is failing. Could you please clarify us that is there anything wrong from IANA tz. If not how can i write my test case according to that?
For a start, you must always take account of the summer transition times forward and back. Across Canada, times change at Sunday 02:00 local time: in March, as each time zone hits 02:00, it becomes 03:00; in November, as each time zone hits 02:00, it becomes 01:00: $ zdump -Vc2020,2021 Canada/Mountain | sed 's/\(Sun\).*\1/\1/' Canada/Mountain Sun Mar 8 01:59:59 2020 MST isdst=0 gmtoff=-25200 Canada/Mountain Sun Mar 8 03:00:00 2020 MDT isdst=1 gmtoff=-21600 Canada/Mountain Sun Nov 1 01:59:59 2020 MDT isdst=1 gmtoff=-21600 Canada/Mountain Sun Nov 1 01:00:00 2020 MST isdst=0 gmtoff=-25200 so to be sure, you need to check on or after each transition, as you will have ambiguous times on Sunday in March between 01:00 and 02:00, and in November between 02:00 and 03:00. In both cases, you could check on or after Sun 03:00. Checking at 12:00 noon is often chosen to be safe regardless of actual transition times, which could vary from 00:00 to 06:00. Similarly, checks are often done on December 31 and June 30 to avoid being near any northern or southern hemisphere transition dates. However in recent years Islamic countries have started to reset summer time changes during Ramadan, which can occur any time in the Gregorian calendar. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
Is Yukon part of Canada/Mountain? Regards, Sundar On Wed, May 20, 2020 at 8:47 PM Brian Inglis < Brian.Inglis@systematicsw.ab.ca> wrote:
On 2020-05-20 05:32, Sundar Sarma wrote:
According to the latest 2020a tz update: Canada's Yukon, represented by America/Whitehorse and America/Dawson, advanced to -07 year-round, beginning with its spring-forward transition on 2020-03-08, and will not fall back on 2020-11-01. We have written a test cases like below for canada yukon timezone. We imported new 2020a tz into our environment. Our code seems correct but test cases are failing. So we found that there is wrong in Iana tz side. Please check and correct us. This is the below code we have written. @Test public void doesNotFallBackToMinus8InDawsonNovember2020() { DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)-------> on 2nd nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> on 1 st nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); long offsetOnDay = timezone.getOffset(day.getMillis()); int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); assertEquals(hoursOnDay, dayAfterHours); -------> here we are getting error: java.lang.AssertionError: expected:<-7> but was:<-8> } The above test case according to your update (will not fall back on 2020-11-01) is correct. But test case is failing. Could you please clarify us that is there anything wrong from IANA tz. If not how can i write my test case according to that?
For a start, you must always take account of the summer transition times forward and back. Across Canada, times change at Sunday 02:00 local time: in March, as each time zone hits 02:00, it becomes 03:00; in November, as each time zone hits 02:00, it becomes 01:00:
$ zdump -Vc2020,2021 Canada/Mountain | sed 's/\(Sun\).*\1/\1/' Canada/Mountain Sun Mar 8 01:59:59 2020 MST isdst=0 gmtoff=-25200 Canada/Mountain Sun Mar 8 03:00:00 2020 MDT isdst=1 gmtoff=-21600 Canada/Mountain Sun Nov 1 01:59:59 2020 MDT isdst=1 gmtoff=-21600 Canada/Mountain Sun Nov 1 01:00:00 2020 MST isdst=0 gmtoff=-25200
so to be sure, you need to check on or after each transition, as you will have ambiguous times on Sunday in March between 01:00 and 02:00, and in November between 02:00 and 03:00. In both cases, you could check on or after Sun 03:00. Checking at 12:00 noon is often chosen to be safe regardless of actual transition times, which could vary from 00:00 to 06:00. Similarly, checks are often done on December 31 and June 30 to avoid being near any northern or southern hemisphere transition dates. However in recent years Islamic countries have started to reset summer time changes during Ramadan, which can occur any time in the Gregorian calendar.
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
On Wed, 20 May 2020 at 12:55, Sundar Sarma <gkssarma59@gmail.com> wrote:
Is Yukon part of Canada/Mountain?
No; Canada/Mountain is a link in the 'backward' file to America/Edmonton which is only present for backwards compatibility and should generally not be used. Splits and differences like this underline the importance of using the correct and supported identifiers wherever possible. -- Tim Parenti
On 5/20/20 4:32 AM, Sundar Sarma wrote:
The above test case according to your update (will not fall back on 2020-11-01) is correct. But test case is failing.
My guess is that you didn't propagate the data into Java. Java doesn't use tzdata's TZif files directly; it builds and installs its own copy of the files and uses that. If Java's copy is obsolete then Java programs will report obsolete results. For more about this see <https://data.iana.org/time-zones/tz-link.html> and look for "Oracle Java". You can test this by running the shell command: zdump -v -c 2020,2021 America/Dawson If older tzdata is installed you'll see this: $ zdump -v -c 2020,2022 America/Dawson America/Dawson -9223372036854775808 = NULL America/Dawson -9223372036854689408 = NULL America/Dawson Sun Mar 8 09:59:59 2020 UTC = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UTC = Sun Mar 8 03:00:00 2020 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 1 08:59:59 2020 UTC = Sun Nov 1 01:59:59 2020 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 1 09:00:00 2020 UTC = Sun Nov 1 01:00:00 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 14 09:59:59 2021 UTC = Sun Mar 14 01:59:59 2021 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 14 10:00:00 2021 UTC = Sun Mar 14 03:00:00 2021 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 7 08:59:59 2021 UTC = Sun Nov 7 01:59:59 2021 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 7 09:00:00 2021 UTC = Sun Nov 7 01:00:00 2021 PST isdst=0 gmtoff=-28800 America/Dawson 9223372036854689407 = NULL America/Dawson 9223372036854775807 = NULL with transitions continuing this fall and next year. In tzdata 2020a you'll see this: $ zdump -v -c 2020,2022 America/Dawson America/Dawson -9223372036854775808 = NULL America/Dawson -9223372036854689408 = NULL America/Dawson Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 MST isdst=0 gmtoff=-25200 America/Dawson 9223372036854689407 = NULL America/Dawson 9223372036854775807 = NULL with transitions stopping after March of this year, and Yukon observing MST now. If you see the latter output then your tzdata is up-to-date; if Java is reporting incorrect results in this area then the problem has something to do with the Java installation, which is downstream from us.
Finally, could you please confirm that is there anything wrong in my code? Still i did not understand why this test case is failing with new 2020a tz. @Test public void doesNotFallBackToMinus8InDawsonNovember2020() { DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone) .withLaterOffsetAtOverlap() .toInstant(); Instant day = new DateTime(2020, 11, 1, 0, 0, timezone) .withLaterOffsetAtOverlap() .toInstant(); long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); long offsetOnDay = timezone.getOffset(day.getMillis()); int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); assertEquals(hoursOnDay, dayAfterHours); } On Thu, May 21, 2020 at 3:31 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 5/20/20 4:32 AM, Sundar Sarma wrote:
The above test case according to your update (will not fall back on 2020-11-01) is correct. But test case is failing.
My guess is that you didn't propagate the data into Java. Java doesn't use tzdata's TZif files directly; it builds and installs its own copy of the files and uses that. If Java's copy is obsolete then Java programs will report obsolete results. For more about this see <https://data.iana.org/time-zones/tz-link.html> and look for "Oracle Java".
You can test this by running the shell command:
zdump -v -c 2020,2021 America/Dawson
If older tzdata is installed you'll see this:
$ zdump -v -c 2020,2022 America/Dawson America/Dawson -9223372036854775808 = NULL America/Dawson -9223372036854689408 = NULL America/Dawson Sun Mar 8 09:59:59 2020 UTC = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UTC = Sun Mar 8 03:00:00 2020 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 1 08:59:59 2020 UTC = Sun Nov 1 01:59:59 2020 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 1 09:00:00 2020 UTC = Sun Nov 1 01:00:00 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 14 09:59:59 2021 UTC = Sun Mar 14 01:59:59 2021 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 14 10:00:00 2021 UTC = Sun Mar 14 03:00:00 2021 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 7 08:59:59 2021 UTC = Sun Nov 7 01:59:59 2021 PDT isdst=1 gmtoff=-25200 America/Dawson Sun Nov 7 09:00:00 2021 UTC = Sun Nov 7 01:00:00 2021 PST isdst=0 gmtoff=-28800 America/Dawson 9223372036854689407 = NULL America/Dawson 9223372036854775807 = NULL
with transitions continuing this fall and next year. In tzdata 2020a you'll see this:
$ zdump -v -c 2020,2022 America/Dawson America/Dawson -9223372036854775808 = NULL America/Dawson -9223372036854689408 = NULL America/Dawson Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 MST isdst=0 gmtoff=-25200 America/Dawson 9223372036854689407 = NULL America/Dawson 9223372036854775807 = NULL
with transitions stopping after March of this year, and Yukon observing MST now. If you see the latter output then your tzdata is up-to-date; if Java is reporting incorrect results in this area then the problem has something to do with the Java installation, which is downstream from us.
On 2020-05-21 12:39, Sundar Sarma wrote:
Still i did not understand why this test case is failing with new 2020a tz.
The version of the IANA database installed in the operating system may well differ from the version used by Java.time. The latter can be determined with the method ZoneRulesProvider.getVersions( String zoneId ). which gives the version used by Java. HTH. Michael Deckers.
after i run this code ZoneRulesProvider.getVersions( String zoneId ). i got below output {2016a=ZoneRules[currentStandardOffset=-08:00]} But in readme file of tzadata, Generated by Gradle I am getting below verison. Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz On Thu, May 21, 2020 at 6:39 PM Michael H Deckers < michael.h.deckers@googlemail.com> wrote:
On 2020-05-21 12:39, Sundar Sarma wrote:
Still i did not understand why this test case is failing with new 2020a tz.
The version of the IANA database installed in the operating system may well differ from the version used by Java.time. The latter can be determined with the method ZoneRulesProvider.getVersions( String zoneId ). which gives the version used by Java.
HTH.
Michael Deckers.
On 2020-05-21 07:09, Michael H Deckers via tz wrote:
On 2020-05-21 12:39, Sundar Sarma wrote:
Still i did not understand why this test case is failing with new 2020a tz.
The version of the IANA database installed in the operating system may well differ from the version used by Java.time. The latter can be determined with the method ZoneRulesProvider.getVersions( String zoneId ). which gives the version used by Java.
From Google and SO, with recent versions, you can do:
$ jshell <<< \ 'System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet());' | Welcome to JShell -- Version 11.0.7 | For an introduction type: /help intro jshell> System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); [2019c] jshell> $ *OR* $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat /usr/lib/jvm/java-1.11.0-openjdk-i386/lib/tzdb.dat:TZDB2019c /usr/lib/jvm/java-11-openjdk-i386/lib/tzdb.dat:TZDB2019c what is actually matched is: $ grep -ao '^...TZDB....[12][90][0-9][0-9][a-z]' /usr/lib/jvm/*/lib/tzdb.dat | cat -A /usr/lib/jvm/java-1.11.0-openjdk-i386/lib/tzdb.dat:^A^@^DTZDB^@^A^@^E2019c$ /usr/lib/jvm/java-11-openjdk-i386/lib/tzdb.dat:^A^@^DTZDB^@^A^@^E2019c$ so there's a code and a byte count and some zeros or nulls, so you could dump just those: $ for dat in /usr/lib/jvm/*/lib/tzdb.dat do echo $dat: head -n1 $dat | cut -c12-16 done /usr/lib/jvm/java-1.11.0-openjdk-i386/lib/tzdb.dat: 2019c /usr/lib/jvm/java-11-openjdk-i386/lib/tzdb.dat: 2019c *OR* equivalents on other systems e.g. for Oracle it should be something like: $ grep -ao '^javazm.....tzdata[12][90][0-9][0-9][a-z]' \ $JAVA_HOME/jre/lib/zi/ZoneInfoMappings *OR* $ head -n1 $JAVA_HOME/jre/lib/zi/ZoneInfoMappings | cut -c18-22 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
On 5/21/20 9:18 AM, Brian Inglis wrote:
System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); [2019c]
Thanks for that jshell recipe. I observe the same "2019c" on my Ubuntu 18.04.4 laptop, even though Ubuntu 18.04.4 has updated tzdata to 2020a, as can be seen from this shell command: $ zdump -V -c 2020,2021 America/Dawson America/Dawson Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 MST isdst=0 gmtoff=-25200 So I am observing the same symptoms that Sundar Sarma reports: my tzdata package is up-to-date but its Java copy is not. There are recipes for fixing the problem by updating the Java copy. For Oracle Java, see <https://www.oracle.com/java/technologies/javase/tzupdater-readme.html>. For OpenJDK or some other Java, you can try ZIUpdater <https://www.azul.com/products/open-source-tools/ziupdater-time-zone-tool/>, tzdbgen <https://github.com/akashche/tzdbgen>, and/or IANA Updater <https://bell-sw.com/pages/iana-updater/>. I'm not going to bother to run any of those since I don't normally run Java apps on my laptop. This Java stuff is all downstream from the tz project proper, so those who have problems with it should contact whoever's maintaining the Java software they're using.
On 2020-05-21 14:33, Paul Eggert wrote:
On 5/21/20 9:18 AM, Brian Inglis wrote:
System.out.println(java.time.zone.ZoneRulesProvider.getVersions("UTC").keySet()); [2019c]
Thanks for that jshell recipe. I observe the same "2019c" on my Ubuntu 18.04.4 laptop, even though Ubuntu 18.04.4 has updated tzdata to 2020a, as can be seen from this shell command:
$ zdump -V -c 2020,2021 America/Dawson America/Dawson Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800 America/Dawson Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 MST isdst=0 gmtoff=-25200
So I am observing the same symptoms that Sundar Sarma reports: my tzdata package is up-to-date but its Java copy is not.
There are recipes for fixing the problem by updating the Java copy. For Oracle Java, see <https://www.oracle.com/java/technologies/javase/tzupdater-readme.html>. For OpenJDK or some other Java, you can try ZIUpdater <https://www.azul.com/products/open-source-tools/ziupdater-time-zone-tool/>, tzdbgen <https://github.com/akashche/tzdbgen>, and/or IANA Updater <https://bell-sw.com/pages/iana-updater/>. I'm not going to bother to run any of those since I don't normally run Java apps on my laptop.
This Java stuff is all downstream from the tz project proper, so those who have problems with it should contact whoever's maintaining the Java software they're using.
There should be coordination within each distro about triggering the local Java package TZ updater when the system tzdata is updated. My weekly cron tzdata release check script would run the TZ Updater against the new release if I still had Java and its TZ Updater installed: it's not hard. Perhaps those with wide deployments of distros with Java packages and apps could submit bug reports against their distro Java packages to apply TZ updates when tzdata packages are updated. Perhaps vendor JVM providers could sponsor packaging their JVM, TZ Updaters, and applying TZ updates when system tzdata is updated on distros they support using, rather than leaving it to system or app support or users. I haven't searched, but apparently even MS Windows now includes tzdata to support their MS Windows store apps or its infrastructure, and must update that, along with their proprietary Windows TZ updates. JVM providers could help more to keep their tzdata up to date, and that could and should be seen as a competitive advantage. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
participants (5)
-
Brian Inglis -
Michael H Deckers -
Paul Eggert -
Sundar Sarma -
Tim Parenti