I've recently discovered firestore.Timestamp and so I tried to assign firestore.FieldValue.serverTimestamp(); to one and it didn't work. instead it says Type 'FieldValue' is not assignable to type 'Timestamp' which I would say is strange. Shouldn't serverTimestamp() be a Timestamp and not a FieldValue? What would be the purpose of firestore.Timestamp if not to save timestamps to Firestore? Is there a way to get a server timestamp that is compatible with firestore.Timestamp or should I be avoiding timestamps altogether, and just stick to firestore.FieldValue for all my dates?
serverTimestamp() just returns sentinel value that tells the Firestore server that it should use the current time on the server as the value for the field you're trying to set. It doesn't return an actual Timestamp object itself.
The reason why you'd use this is to make sure that dates are being set consistently on the server instead of depending on the clock being correct on the user's device.
If you want to know the current time on the device, just use the native date/time objects provided by the language or operating system.
Related
I am having a hard time using ts field in cosmos/document db with c#. Is it just better to create another date time field and use that instead of ts? How to decide when to use ts vs a custom date time field?
_ts represents a Unix Epoch and marks the time of the document's last modification. When a document is created, it has the creation time, but if later on the document is updated, then _ts is updated with that time.
Effectively it means the last modified time of the document.
It depends on your use case if you can use it or you need a custom date field. For example, if your intent it to track when a document was created, then you can't use it, as the value will change if the document is modified. If your intent is to track the last modified time, it can work (depends on the precision you need and if a Unix Epoch fills that requirement, otherwise you would need your own custom field).
Here is the official reference of system properties: https://learn.microsoft.com/azure/cosmos-db/account-databases-containers-items#properties-of-an-item
I have Firestore documents that use Timestamp. I've checked every part of my code and I'm 100% sure the Instants I use to create timestamp always contain only dates like 2020-05-01T00:00:00Z. However, when I look a the https://console.firebase.google.com I see strange things. Each timestamp has suddenly additional time in it. It's either 1:00:00 AM UTC+1 or 2:00:00 AM UTC+2.
In order to turn Instant to Timestamp I use this extension:
fun Instant.toTimestamp(): Timestamp {
return Timestamp.ofTimeSecondsAndNanos(this.epochSecond, this.nano)
}
How is it possible that correct data on the client side becomes incorrect when saved? What am I missing here?
I use batch updates and I also checked the mutations it contains and everything is fine there too. I converted all its timestamps back to Instants and none of them contained time. Why do they appear in the console?
Timestamps don't encode a timezone - they are always UTC. However, the Firebase web console displays timestamps using the timezone configuration of the local machine running the browser (for local readability). If you query for the document and get the timestamp back out, it will be the same as the time you put in (again, internally represented in UTC).
-order
-amount: 125
-date: 13/11/2019
-id: "SAV-00000001"
I am trying to add some data, something similar to above. I want the date field to be stored as a date object so that when I query it I can order by date.
When I add a date it's being stored as a string. Is there a way to make sure that it's stored as a date object instead?
Note: The questions I have found talk about how to add a date programmatically, but I'm trying to find out how to add it manually via the console.
Firstly, there is no "date" type provided by Realtime Database. You'll have to choose your own format for dates, and those will usually be a string or a number.
Second, the Firebase console doesn't have a field editor for date-related strings or numbers. If you need a string or number, you're going to have to just type that yourself into the console, or create your own tool to make that easier.
I have some documents indexed in Solr that contain some timestamps, like that:
2017-10-21T11:53:33Z.
When I perform queries form Solr Admin UI, I get the correct information (the exact timestamps).
However, when I perform queries from SolrJ, I get the following timestamps:
Sat Oct 21 14:53:33 EEST 2017
The field that stores this timestamp has the following type: org.apache.solr.schema.TrieDateField
So the format and the timezone is changed. I read this post and this one and I understand that SolrJ takes into consideration the local timezone when it retrieves dates, but why is this happening?
Also, the format is changed and I don't want that! I want the exact same format that I input when I index dates to Solr.
How can I change this date format when I retrieve dates from Solr using SolrJ and how can I retrieve the exact values (the exact timezone) that I can see when I use Solr Admin UI?
SolrJ parses the response from Solr, converts string "2017-10-21T11:53:33Z" to a Date object and returns you it.
By default, the timezone is printed in your local timezone (EEST), so it just a representation, but the date/time is the same. You can convert it and display in any timezone.
For example see this answer: https://stackoverflow.com/a/22364501/937970
Another option is to set a global timezone for your JVM, but this might affect the whole application:
java -Duser.timezone=UTC ...
When you make a query using Solr Admin UI it just returns you raw values, that's why you see the UTC value.
In our application we're getting initialValues for a form from an API call that returns something like:
{
myDate: "2000-01-01T00:00:00"
}
We then convert that value to a moment and save it to the store and populate initialValues from that. If we then select a new value (say, 2001-01-01, also a moment) and save the form, we read the response back from the api, convert it back to a moment, and throw it back in initialValues. The problem is, now our field is dirty because moment("2001-01-01") !== moment("2001-01-01").
Is our workflow wrong? Is there a better way to handle managing initialState?
The problem is that if moment("2001-01-01") does not equal moment("2001-01-01") then redux-form will always think that the form state has changed if the value for myDate is reinitialized, even though the value used to create the Moment instance is the same.
The fix is simple: Don't store moment objects in the redux store. Instead use a formatted string, like "2000-01-01T00:00:00", or or a number (unix timestamps) to represent datetime information in the redux store. If you need to do operations, like date1.isBefore(date2), you can convert them to Moments temporarily.