We Keep Coding

Google cloud - get current time offset from UTC of timezone (when timezone is described using Supported Time Zone Value)

I'm including timezone identifiers as strings, in data that's being stored in Google Cloud DataStore, and I want to get the current time offset from UTC (including any adjustment for daylight saving time), for that timezone identifier. For example I want to return something like -08:00, or +6:00
The identifiers I'm using are the (Supported Time Zone Values) (these appear to be timezone identifiers defined by Trifacta, which is a partner of Google that provides data prep capabilities) - the Google documentation appears to be a dupe of Trifacta's own documentation - https://docs.trifacta.com/display/SS/Supported+Time+Zone+Values.
The Google documentation says this in relation to the Supported Time Zone Values:
For the functions that support use of specified time zones, you can
apply the [Supported Time Zone Values] as parameters to specify the time
zone
So, I'm wondering if there might be functions (either in Java, or in GQL) that will accept a Supported Time Zone Value and return an offset, or allow it to be derived? For example I'm wondering if there's something available in Trifacta or GQL that's like the AT TIME ZONE in SQL Server 2016.
How can I return the current offset to UTC based on the Supported Time Zone Value?

The only GCP product that uses the Supported Time Zone Values afaik is Cloud Dataprep by Trifacta. The time zone values are taken by functions NOW and TODAY. In java, you can take a look at ZoneOffset class, but I'm not sure if you can incorporate all the identifiers form Trifacta.

if I understand correctly you are trying to modify most current dates at your timezone based on an offset. This is achievable with the combination of functions using NOW and DATADD in Trifacta.
Refer the article here to get more clarity on this https://community.trifacta.com/s/article/Function-NOW-DATEADD-and-DATEDIF
Best
Vardan

Not getting the correct timezone in java

The code that I am using to get the current timezone in java side is as follows:
Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("America/Los_Angeles"));
System.out.println("the timezone is--->"+(TimeZone.getTimeZone("America/Los_Angeles")).getDisplayName());
It is displaying as pacific Standard Time
but the current time zone in america/los angeles is pacific daylight time
Can anyone help me with this?

You're calling the parameterless getDisplayName() method whose documentation includes:
This method is equivalent to:
getDisplayName(false, LONG, Locale.getDefault(Locale.Category.DISPLAY))
The false here is the argument which specifies "don't use daylight saving time". So the parameterless method will never display a DST variation.
It's not clear that you really should usually display a name based on the current standard/daylight part - but if you really want to, you can use:
String name = zone.getDisplayName(zone.inDaylightTime(new Date()), TimeZone.LONG,
Locale.getDefault(Locale.Category.DISPLAY));
Obviously you should customize the second and third parameters according to your requirements.

Time stamp class in org.apache.commons.net package

I want to use time stamp as part of my application(I am using JAVA).I was asked to use Network Time Protocol(NTP).I have searched in google and I was able to find a package "org.apache.commons.net" where there is a TimeStamp class.I have gone through this link to know more about the class.
What should I pass to the constructors of this class(what is the significance of each constructor). Actually TS class should return us the time stamp,instead it is asking to input time stamp.I am confused with that.

You can use the following overload of the constructor to create the TimeStamp Object.
public TimeStamp(Date d)
pass an object of java.util.Date as argument.
This will give you a timestamp value which is represented as a
64-bit unsigned fixed-point number in seconds relative to 0-hour on 1-January-1900.
The main significance is that it is a protocol, a standard followed by different systems. Different systems present in a network may not have their clock synchronized, and may not understand how others are measuring time, may follow different time zones. using NTP they synchronize their clock to UTC

You can use the static getCurrentTime() to get a timestamp that represents the current time measured to the nearest milliseconds:
Timestamp myTs = Timestamp.getCurrentTime();

What is the Objective-C equivalent of the Java TimeZone?

What is the Objective-C equivalent of the Java TimeZone class?

The NSTimeZone class is the equivalent of the Java TimeZone class.

NSTimeZone, I believe. Can't say I've ever done any Objective-C myself, but it looks right...
Apple also has a (pretty short) article on using it.
It's quite likely that they won't be direct equivalents in every respect, of course... but if there's something you would use with Java's TimeZone which you can't figure out in NSTimeZone, ask about that specific call... and someone else can help you, I'm sure :)
EDIT: The purpose of a time zone class is to convert between local times in different time zones. For example, right now, it's 7.50pm for me - but it's 12.50pm for the person who I'm about to have a Skype call with. One option for representing dates and times is to always store them in UTC (which is sort of the "zero" of time zones) and then convert the UTC value into the "local" time for the user, e.g. for display purposes. That's not always the right option, but it's usually a good starting point.
At other times, you may have a local time and know person X's time zone - and want to convert it to person Y's time zone. It's usually easiest to do that by converting the local time to UTC (using X's time zone) and then to convert it back to local time using Y's time zone.
Time zones aren't nearly as straightforward as you might expect - mostly due to daylight savings. Oddities:
Local times which either don't exist, or occur twice, due to DST transitions
Time zones which change to DST at midnight, so that midnight doesn't always exist
Governments deciding to scrap (or introduce) DST at almost no notice
DST which isn't the normal "move an hour forwards". IIRC, Tibet was considering introducing DST of 1:15.
Historical changes to time zones
The list goes on.

NSTimeZone : http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSTimeZone_Class/Reference/Reference.html
Regards.

What system default date format to use?

I'm setting the standards for our application.
I've been wondering, what default date format should I choose to use ?
It should be:
Internationalization & timezone aware, the format should be able to represent user local time
Can be efficiently parsed by SimpleDataFormat (or alike, jdk classes only)
Programming Language agnostic (can parse in java, python, god forbid C++ :) and co.)
Preferably ISO based or other accepted standard
Easy to communicate over HTTP (Should such need arises, JSON or YAML or something in this nature)
Can represent time down to seconds resolution (the more precise the better, micro seconds if possible).
Human readable is a plus but not required
Compact is a plus but not required
Thank you,
Maxim.

yyyy-MM-ddThh:mmZ (See ISO 8601) You can add seconds, etc
You can read it easily, it will not be a problem for SimpleDateFormat.

The most canonical and standard form is probably "Unix Time": The number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970.
If you set that as the default time-format you can easily parse it, store it in memory, write it to disk, easily communicate it over HTTP and so on. It is also definitely an accepted standard, and in a sense it is "time-zone aware", since it is well-defined regardless of time-zones.
(This is the format in which I always store all my time stamps; in databases, in memory, on disk, ...)

The "right" default format really depends on what you're doing with it. The formats for parsing, storing, and displaying can all be different.
For storing the date you're (almost) always going to want to use UTC as aioobe says, even when you want to display it in user local time. I say "(almost)" but I really can't think of a case where I would not want UTC for a saved date. You may want to store the TZ information for where the date originated also, so you can report it in that local time, but more often you want to display the local time for the whoever is currently looking at the date. That means having a way to determine the current user's local time regardless of what the original local time was.
For displaying it, the "default format" should usually be determined by the viewers locale. 08/09/10 usually means 2010-Aug-9 in the U.S. ("Middle endian") but normally means 2010-Sep-8 in most of the rest of the world ("Little endian"). The ISO-8601 format "2010-09-10" is safe and unambiguous but often not what people expect to see. You can also look over RFC-3339 for Date and Time on the internet and RFC-2822 for message format (transmitting the date)
For parsing a date, you'll want to parse it and convert it to UTC, but you should be fairly flexible on what you accept. Again, the end users Locale and timezone, if discoverable, can help you determine what format(s) of string to accept as input. This is assuming user-typed strings. If you're generating a date/time stamp you can control the form and parsing will be no problem.
I also second BalusC link which I hadn't seen before and have now favorited.