In ballerina time packages createTime function, it asks for zoneID as a function parameter, when I provide a custom zoneID, program keeps running without any output. Is there a way to find those predefined time zoneIDs with relevant timezones?
The underlying implementation of ballerina time package is Java and the zone ID processing rules are similar to the Java rules. Basically rules are as follows.
If the zone ID equals 'Z', the result is UTC. If the zone ID equals
'GMT', 'UTC' or 'UT', it is equivalent to UTC.
If the zone ID starts with '+' or '-', the ID is parsed as an offset.
Offset can be specified in one of the following ways.
+h,
+hh,
+hh:mm,
-hh:mm,
+hhmm,
-hhmm,
+hh:mm:ss,
-hh:mm:ss,
+hhmmss,
-hhmmss
Also zone id can be a region-based zone ID. The format is '{area}/{city}' eg: "America/Panama". The zones are based on IANA Time Zone Database (TZDB) supplied data.
Ex:
Using UTC
time:Timezone zoneValue = {zoneId:"Z"};
time:Time time = new(1456876583555, zoneValue);
Using offset
time:Timezone zoneValue = {zoneId:"-05:00"};
time:Time time = new(1456876583555, zoneValue);
Using region-based zone ID
time:Timezone zoneValue = {zoneId:"America/Panama"};
time:Time time = new(1456876583555, zoneValue);
We hope to improve this API in a future version of Ballerina with proper representation for the zone ids etc.
You can refer to the Ballerina date time example for more details.
Related
This question already has answers here:
How to make a timezone aware datetime object
(15 answers)
Closed 6 years ago.
I've got a datetime which has no timezone information. I'm now getting the timezone info and would like to add the timezone into the existed datetime instance, how can I do?
d = datetime.datetime.now()
tz = pytz.timezone('Asia/Taipei')
How to add the timezone info tz into datetime a
Use tz.localize(d) to localize the instance. From the documentation:
The first is to use the localize() method provided by the pytz library. This is used to localize a naive datetime (datetime with no timezone information):
>>> loc_dt = eastern.localize(datetime(2002, 10, 27, 6, 0, 0))
>>> print(loc_dt.strftime(fmt))
2002-10-27 06:00:00 EST-0500
If you don't use tz.localize(), but use datetime.replace(), chances are that a historical offset is used instead; tz.localize() will pick the right offset in effect for the given date. The US Eastern timezone DST start and end dates have changed over time, for example.
When you try to localize a datetime value that is ambiguous because it straddles the transition period from summer to winter time or vice-versa, the timezone will be consulted to see if the resulting datetime object should have .dst() return True or False. You can override the default for the timezone with the is_dst keyword argument for .localize():
dt = tz.localize(naive, is_dst=True)
or even switch off the choice altogether by setting is_dst=None. In that case, or in the rare cases there is no default set for a timezone, an ambiguous datetime value would lead to a AmbiguousTimeError exception being raised. The is_dst flag is only consulted for datetime values that are ambiguous and is ignored otherwise.
To go back the other way, turn a timezone-aware object back to a naive object, use .replace(tzinfo=None):
naivedt = awaredt.replace(tzinfo=None)
If you know that your original datetime was "measured" in the time zone you are trying to add to it, you could (but probably shouldn't) use replace rather than localize.
# d = datetime.datetime.now()
# tz = pytz.timezone('Asia/Taipei')
d = d.replace(tzinfo=tz)
I can imagine 2 times when this might make sense (the second one happened to me):
Your server locale is set to the incorrect time zone and you are trying to correct a datetime instance by making it aware of this incorrect timezone (and presumably later localizing it to the "correct" time zone so the values of now() match up to other times you are comparing it to (your watch, perhaps)
You want to "tag" a time instance (NOT a datetime) with a time zone (tzinfo) attribute so that attribute can be used later to form a full datetime instance.
I have a SQL DATETIME field DT that I want to feed into Kafka using Avro. DT is in local time but has no time zone; that's stored in another column TZ as an offset from UTC in minutes. It seems that an Avro timestamp-millis would be appropriate for DT, but I'm confused about conversion, given the lacking time zone. From looking at the connector source code, I think it will just default to UTC.
So that raises the questions:
Will all visibly similar datetimes convert to the same number of milliseconds since the/an epoch, regardless of their nominal time zone? For example, does (2018-01-01T00:00Z).to_timestamp_ms() == (2018-01-01T00:00).to_timestamp_ms() == (2018-01-01T00:00+05).to_timestamp_ms()?
More importantly, is it possible to convert to true UTC after ingestion by subtracting the time zone offset TZ from the datetime field DT (which is now in milliseconds since some epoch)? In other words, if the connector incorrectly assumes UTC, and falsely interprets the datetime as UTC, can the true datetime be recovered after that by subtracting the offset?
Details on transformation steps
I think the order of operations is something like this on the Connector (largely out of my control):
tz = read_field_as_int('tz')
dt = read_field_as_string('dt')
parsed_datetime = datetime(dt, timezone=UTC)
message = {
'dt': parsed_datetime.to_timestamp_ms(),
'tz': tz
}
producer.produce(message)
And then later, in the consumer, maybe this would work?
ms_per_min = 60 * 1000
message = consumer.poll()
true_timestamp = message['dt'] - message['tz'] * ms_per_min
true_dt = datetime.from_timestamp(true_timestamp, timezone=UTC)
I'm using Joi package to validate a timestamp field but How can I set a max() value on it, I want the input timestamp to be less than current time stamp
var schema = Joi.object().keys({
t: Joi.date().timestamp('unix').max(moment().unix()),
})
but I get the error that:
child "t" fails because ["t" must be less than or equal to "Sun Jan 18
1970 07:35:17 GMT+0330 (IRST)"]
I'm sure that the moment().unix() returns the current timestamp, but here it is casted to string.
It seems that max() and min() functions can do the trick but they only work if the threshold is specified in milliseconds.
t: Joi.date().timestamp('unix')
.max(moment().unix() * 1000)
.min(moment().subtract('42', 'weeks').unix() * 1000),
It doesn't look like Joi.date().max() accepts unix timestamps properly despite being able to specify in your schema that a unix timestamp is expected for incoming values.
If you need to use the current date in your schema you can pass the string 'now' instead of using the date. Or just make sure you enter the current date in format that .max() expects. I tried this using milliseconds and it seems to work as expected. I think Joi is using the default Date constructor under the hood to construct dates to compare which expects milliseconds.
var schema = Joi.object().keys({
t: Joi.date().timestamp('unix').max(moment().unix() * 1000)
});
From the docs on date.max()
Notes: 'now' can be passed in lieu of date so as to always compare relatively to the current date, allowing to explicitly ensure a date is either in the past or in the future.
I've read thru various posts on here in regards to similiar issues but none have solved my problem.
I manipulate the moment.js date object, and then store it as timestamp.
BUT, when I try to read in that timestamp again, I get that deprecated warning.
""Deprecation warning: moment construction falls back to js Date. This is discouraged and will be removed in upcoming major release. Please refer to https://github.com/moment/moment/issues/1407 for more info."
I've tried toDate(), format(), moment(myTimeStamp, 'ddd, DD MMM YYYY HH:mm:ss ZZ'); --> all generate the warning...
So, for example, my timestamp will look like this:
const timestamp = '1458586740000'
when I read that back and try to parse out the month/day/year, then the hour/min am/pm, etc... I need to get that timestamp into a moment.js object. Nothing is working for me. Any ideas.
How can I get this timestamp: '1458586740000', into a moment.js object so I can extract date date from it as I need?
EDIT: this is how I am storing the timestamp. So I would need to retrieve it from this.
let timeStamp = Moment(state[_Date])
.add({ hour: state[AMPM] === 'PM'
? +state[Hour] + 12
: state[Hour] ,
minute: state[Min] }).format('x')
The X token indicates a unix timestamp in seconds, and the x token indicates a unix millisecond timestamp (offset).
You appear to have a millisecond timestamp, so you would make a moment out of it by doing the following:
var a = moment('1458586740000', 'x')
It works without ' as well:
var a = moment(1458586740000, 'x')
You can also not specify the x and it should work:
moment(1458586740000)
Because you have a unix offset (milliseconds), not a unix timestamp (seconds), moment.unix is not what you want.
Then you can do the following:
a.format()
"2016-03-21T13:59:00-05:00"
Or you can use any of the other formatting tokens listed here to output whatever result you would like: http://momentjs.com/docs/#/displaying/format/
Based on the code you presented, I think you may be having problems because your timestamp is stored as a string (in ''). Parsing as a string causes an invalid date error, because it attempts to match ISO 8601 format and fails. Specifying that 'x' token will cause it to assume unix offset and work correctly.
I have a scenario where i need to convert a Datefield(joindate) to currentcompany timezone date. And then i need to compare this with anotherdate(startdate). If the difference is more than 365 days i need to give an warning. Can someone help me in this.
Thanks in advance.
You can apply a timezone to an utcdatetime via DateTimeUtil::applyTimeZoneOffset
The company timezone can be retrieved by calling DateTimeUtil::getCompanyTimeZone
Afterwards calculate the difference by calling DateTimeUtil::getDifference, which returns the difference in seconds so you have to compare that with the seconds per year.
To avoid inserting a 'magic' number, use the constants in the macro library TimeConstants.
If Datefield(joindate) is of type date and not utcDateTime then DateTimeUtil::newDateTime() should be used to convert it to utcDateTime:
utcDateTime joinDateTime = DateTimeUtil::newDateTime(joindate, 0,
DateTimeUtil::getCompanyTimeZone());
DateTimeUtil::getDifference() can be used to get the number of seconds between the utcDateTime values.
If both Datefield(joindate) and anotherdate(startdate) are of type date and not utcDateType then no conversion is required at all, and you can check whether the difference is more than 365 as follows:
if (joindate - startdate > 365) {}
If the above assumptions are wrong, see DAXaholic's answer.