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.
Related
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).
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.
Date string should not be converted to local time zone. We want to show the user the date in which record is created. Due to timezone changes we have observed that date is changing.
In web we are removing the time zone so that we we are able to show the date as is.
When we get data from server we are not getting the time zone (Its GMT time). But after saving to jsonstore its getting converted to local time zone and due to that date is getting changed in some cases.
Data received from server - "2019-06-13T00:00:00-05:00"
Data received from json store - "2019-06-13T10:30:00+05:30"
Expected result - "2019-06-13T00:00:00-05:00"
JSONStore stores data as, well, JSON. JSON doesn't have a Date format while JavaScript objects do.
So, when you're writing to the JSONStore, you should convert it to a suitable format that you want - either String or time since epoch. If you convert to String, you can read it out from JSONStore as-is, but the drawback is that you cannot do arithmetic operations on the date without making another conversion.
If you store the time since epoch, you will have to convert it to the desired time zone and then display to your users.
I looked on the documentation for google big query data types, checking the differences between TimeStamp to Datetime data types.
As I understand the main difference is:
Unlike Timestamps, a DATETIME object does not refer to an absolute instance in time. Instead, it is the civil time, or the time that a user would see on a watch or calendar.
So when should I use Timestamp/Datetime?
Thanks
In most cases you will want to use the timestamp data type. It refers to an absolute point in time. BigQuery interprets any timezone information and represents the time internally as a UTC timestamp.
Very rarely would you use a datetime data type, which is a date and a time but no time zone. The example I like to give is that you'd use a datetime to represent pi day, 2017, since it occurs at 2017-03-14 15:09:26.535898 in each time zone separately.
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.