Server timestamps in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding Firebase Server Timestamps Behavior

When you set a field in a Firestore document to firebase.firestore.FieldValue.serverTimestamp(), what will be the value of that field immediately after the write operation completes on the client?

A The exact server time at the moment the write was processed by Firestore.

B A placeholder value that will be replaced asynchronously with the server timestamp once confirmed.

C The client's local time at the moment the write was initiated.

D Null, because the server timestamp is not available on the client.

💡 Hint

Think about how Firestore handles latency and synchronization between client and server.

When you write serverTimestamp(), Firestore sets a placeholder on the client. This placeholder is replaced asynchronously with the actual server time once the server confirms the write. This allows the client to show a temporary value while waiting for the server.

❓ Configuration

intermediate

Using Server Timestamps in Firestore Document Updates

You want to update a Firestore document's lastModified field to the current server time. Which of the following update commands correctly sets the lastModified field to the server timestamp?

Firebase

const docRef = firestore.collection('users').doc('user123');

// Which update command is correct?

A docRef.update({ lastModified: firebase.firestore.FieldValue.serverTimestamp() });

B docRef.update({ lastModified: new Date() });

C docRef.set({ lastModified: firebase.firestore.FieldValue.serverTimestamp() });

D docRef.update({ lastModified: firebase.firestore.Timestamp.now() });

💡 Hint

Consider which method updates only the specified fields and which value represents the server timestamp.

Using update() with firebase.firestore.FieldValue.serverTimestamp() sets the field to the server time. set() replaces the whole document unless merge is used. new Date() uses client time, and Timestamp.now() is client-side timestamp, not server.

❓ Architecture

advanced

Designing a Firestore Schema with Server Timestamps for Audit Logs

You are designing an audit log system in Firestore that records user actions with timestamps. You want to ensure timestamps are consistent and trustworthy. Which architecture choice best achieves this?

A Store timestamps as strings formatted on the client side for readability.

B Use client-generated timestamps with <code>new Date()</code> and trust client clocks.

C Use <code>firebase.firestore.FieldValue.serverTimestamp()</code> for all timestamp fields to ensure server time consistency.

D Use a Cloud Function to add timestamps after writes, ignoring client timestamps.

💡 Hint

Think about trustworthiness and consistency of timestamps in distributed systems.

Using serverTimestamp() ensures all timestamps come from the server, avoiding client clock skew or manipulation. This is critical for audit logs. Cloud Functions can add timestamps but add complexity and latency. Client timestamps are unreliable.

❓ security

advanced

Securing Firestore Writes with Server Timestamps

You want to prevent clients from spoofing timestamps in Firestore writes. Which Firestore security rule best enforces that the createdAt field is set only to the server timestamp?

A allow write: if request.resource.data.createdAt == request.time;

B allow write: if request.resource.data.createdAt == request.resource.data.createdAt;

C allow write: if request.resource.data.createdAt == request.auth.token.timestamp;

D allow write: if request.resource.data.createdAt != null;

💡 Hint

Consider how Firestore security rules access server time and request data.

In Firestore security rules, request.time is the server timestamp at the time of the request. Comparing createdAt to request.time ensures the client cannot spoof the timestamp. Other options either compare to client data or are always true.

✅ Best Practice

expert

Handling Missing Server Timestamps in Offline Firestore Clients

When a Firestore client is offline and writes a document with a serverTimestamp() field, what is the best practice to handle the timestamp field in your app UI before the client reconnects?

A Set the timestamp field to null and never update it.

B Show the client's local time as the timestamp immediately after the write.

C Hide the timestamp field completely until the client reconnects.

D Display a loading indicator or placeholder until the server timestamp is available.

💡 Hint

Think about user experience and data consistency when server data is delayed.

Since server timestamps are placeholders offline, showing a loading indicator or placeholder informs users the timestamp is pending. Showing client time risks confusion. Hiding or nulling loses context or misleads users.