I am currently exploring Learning locker which is a LRS and store XAPI statements .I see the timestamp in XAPI should follow ISO 8601 format .I see it can be represented as "2015-01-01T01:00Z" but how can I store the timezone information too like "2007-04-05T12:30−02:00".XAPI documentation suggests setting the timeozone but there is no clear way how we can do it .
Any clue on this will be helpful .
Generally the Z indicates a timezone, specifically the UTC timezone. It is preferred that all statement timestamps are stored using UTC and then if they need to be handled relative to a local timezone then that conversion happens at the point of need rather than via the stored data. If you must store it with the specific timezone then the format you showed with the -02:00 should work. NOTE: In the proposed (nearly accepted) version 2.x of the xAPI specification all timestamps will have to be recorded in UTC, see:
A Timestamp shall be formatted to UTC
(https://gitlab.com/IEEE-SA/xapi/9274.1.1/xapi-base-standard-documentation/-/blob/master/9274.1.1%20xAPI%20Base%20Standard%20for%20Content.md#527-additional-requirements-for-data-types)
So it would likely be better to go ahead and start following that pattern.
If the timezone is relevant for other purposes it would be better to track the timezone itself separately from the timestamp (likely as a result or context extension).
Related
I would like to convert times from pacific to UTC. However, I must first convert the times to either PST or PDT depending on the date. Is there a SQL function that can do this, or does anyone have any advice for creating this function?
The link you provided is pretty much useless as a guide to timestamps. If you are going to work with timezones then store your timestamps in a timestamp with time zone field. The timezone will not actually be stored but the timestamp will be stored as a UTC. Whenever a timestamp is entered it is rotated to a UTC value. This makes working with value easier down the road. If you want to take into account DST transitions you will need to use full timezone names e.g. US/Pacific, as they cover the two offsets(PST/PDT) that constitute the standard/daylight savings timezones. As you found using the offset PST(-08) or PDT(-07) gets you a fixed offset regardless of date.
I want to use MomentJs to convert Firestore Timestamp (which is by Default UTC) to UTC+1. How can I do that?
firestore.Timestamp.now().toDate()
P.S. I dont want to use the local/device's time.
Firestore Timestamp (which is by Default UTC)
There is no "default" really. When you have a Timestamp object (or a JavaScript Date, or any other native date object from a modern operating system), the moment in time is always represented internally in UTC.
When you call toDate() on a timestamp, the resulting Date is still internally represented in UTC.
Don't be confused about the "default" string representation of a Date object. It will appear in the local timezone where the computer's operation system is configured. But internally, it's still UTC.
If you want to format the timestamp as a string for another timezone, you can certainly do that. momentjs has an accompanying library Moment Timezone that can help you with that. The momentjs library itself will not help you with timezones (other than the one provided by the local of the system where it is running), as it's generally understood that native timestamps are always UTC.
We are working on an API that has an authentication header in which a timestamp has to be processed. Since we might need more use of timestamps in the future and want to be consistent in what timezone we use, I'd like to know if there is a conventional timezone for APIs. UTC+0 for example.
Thanks in advance
In some cases, you will find that HTTP headers (such as the standard Date header) is in RFC5322 format (aka RFC2822, RFC822). For example: Tue, 31 Jan 2017 17:45:00 GMT
In the Date header, the time zone abbreviation is always"GMT" (which is equivalent to UTC for this purpose), even though the RFC5322 format allows for other time zones.
The above format is not really preferred, it's just something we're stuck with. You can certainly use any format you wish for your own HTTP headers though.
A much better format is the RFC3339 format. This is similar to the ISO8601 extended format. An example is: 2017-01-31T17:45:00Z. The Z at the end indicates "Zulu" time, which is the same as GMT or UTC. However, you could also specify a time zone offset from UTC, such as the equivalent local time in the US Pacific time zone: 2017-01-31T09:45:00-08:00
If you have Unix time numbers like 1485884700, the time zone is always UTC. However, this is not a good interchange format because it is not human readable, and offers no context for what epoch or precision is being used. One would have to know those things externally. It is not a good fit for HTTP headers, nor XML or JSON.
If you are talking about the body of your XML/JSON requests, then you should only be using ISO8601. There are a few other formats that people use, but they are not recommended.
With regard to what time zone you should use - that's entirely dependent on context. If you are timestamping - where you take the current time and record it, then you can indeed just work with UTC. I would think for authorization purposes, this would be reasonable. You could also work in a local time, as long as you provided the offset from UTC along with it so there is no ambiguity.
However, you said (in comments) that your data contains information about job vacancies. That sounds to me like you are talking about time in the future - and that is an exception to the "always UTC" rule. Any time you are talking about time in the future, you need to express that in terms of local time, in the most direct form you can, and you also need to provide the identifier (not the offset) of the time zone that applies.
For example, if I am talking about a job vacancy, I might say in my data:
{
"job": "dishwasher",
"available: "2017-02-13",
"start": "08:00",
"end": "16:00",
"tz": "America/New_York"
}
These values would follow the ISO8601 format for date-only and time-only (or if I wanted to combine them 2017-02-13T08:00) - and would not have a time zone specified. Instead, the IANA time zone identifier America/New_York (for US Eastern Time) is provided in a separate field.
This matters because perhaps the job continues into future months. On March 12th, the US Eastern time zone will change from UTC-5 to UTC-4. Therefore, one cannot specify a single offset, nor can you use UTC.
Also, even for a single occurrence, keep in mind that some countries continue to change their minds about what their time zone and DST rules are, which is why there are dozens of updates to the tz database every year. If you were to calculate an offset for a date and time in the future, by the time it rolls around you might find the offset had been changed by the government.
I have a TIMESTAMP field in an hsqldb table that I want to set to "2015-02-11 16:02:01.488 America/Los_Angeles", but the insert fails even if I set the column to TIMESTAMP WITH TIMEZONE, the reason being hsqldb seems to support '2008-08-08 20:08:08-8:00' format but not spelled out like America/Los_Angeles. Is there way to make the insert accept America/Los_Angeles type zones ?
Sorry, but hsqldb doesn't support working with IANA/Olson time zones directly. You are correct that TIMESTAMP WITH TIMEZONE only supports a time zone offset. You can review the hsqldb docs for confirmation.
Many databases do not support named time zone. Oracle and Postgres support them, but most others do not.
Consider also that while a named time zone can usually determine the offset, there are still cases of ambiguity around the fall-back daylight saving time transition. In other words, if you had "2015-11-01 01:30:00 America/Los_Angeles", you could not deterministically tell whether it was Pacific Daylight Time (UTC-07:00) or Pacific Standard Time (UTC-08:00). This is why usually just the offset is stored.
The converse is also true though. If you only store "-08:00" then you can't deterministically know that it came from "America/Los_Angeles".
Here's a general guideline that will help:
If the local time is unimportant, then just store a TIMESTAMP based on UTC.
If the local time is important, but the value will never be modified, then store a TIMESTAMP WITH TIMEZONE, using the local time and it's associated time zone offset.
If the local time is important AND the value can be modified, then store a TIMESTAMP WITH TIMEZONE in one column, and the time zone name (ie. "America/Los_Angeles") in a second VARCHAR column, or elsewhere in your database. During an edit operation, use the time zone name to calculate the offset of the new value. It might be the same, or it may be different.
See also DateTime vs DateTimeOffset, which presents a similar argument for .Net and/or SQL Server.
Q1: I want to convert a unix timestamp (INT) to monetdb timestamp ('YYYY-MM-DD HH:MM:SS') format
but it is giving me the GMT time not my actual time.
When I do
select (epoch(cast(current_timestamp as timestamp))-epoch(timestamp '2013-04-25 11:49:00'))
where 2013-04-25 11:49:00 is my systems current time it gives the same difference
I tried using
set time zone interval '05:30' HOUR TO MINUTE;
but it did not change the result
How can I solve this problem??
Example Problem:
I wanted to convert unix timestamp 1366869289 which should be around "2013-04-25 11:25:00" but monetdb gives "2013-04-25 05:55:00"
Knowing nothing about MonetDB, but a lot about timezones, I decided to look in their documentation to see what kind of datatypes are supported and how conversions are handled.
I found this page on Temporal data types. Based on that, I can conclude that a timestamp in MonetDB is always intended to reference UTC/GMT time - which is consistent with other systems.
In order to get a value that is for a particular time zone, they offer the following example:
SET TIME ZONE INTERVAL '1' HOUR TO MINUTE
I assume this means to set the database to offset all times by 1 hour, effectively placing the values all in UTC+01:00, such as is the offset for British Summer Time.
The page also goes on to point out the problems that can arise with using just and offset to adjust time values (see TimeZone != Offset in the TimeZone tag wiki). It also offers a list of various named time zones. But it does not show how to set a time zone to one of the named values. Also, their list appears to be proprietary, and incomplete. While at first glance they appear to have similarities to the IANA/Olson time zone database - the identifiers they specify are not valid TZDB names.
There are some other functions listed on this page, without much explanation. One that looks promising for your needs is LOCALTIMESTAMP. Perhaps this will take the local time zone into account, which appears to be what you were looking for.
I could not find any additional details specific to MonetDB date/time/timezone handling. The documentation appears to be fairly incomplete. You might want to reach out to their mailing list.