DEV Community: nishchal singh

Why Date and Time Bugs Happen in JavaScript (And How Apps Actually Get It Right)

nishchal singh — Tue, 10 Feb 2026 11:46:37 +0000

If you’ve ever seen reminders fire early, late, or on the wrong day,

this post is for you.

I used to think date and time bugs were just edge cases.

They’re not.

Most of the time, they come from a slightly wrong mental model of how
time actually works in JavaScript. The problem only becomes visible
when an app starts dealing with real users, real schedules, and real
expectations.

This post explains why these bugs happen so often, how JavaScript really
handles date and time, and how production apps avoid them.

No heavy theory.
No library comparisons.
Just the parts that matter.

The illusion: “I used `Date()`, so time should be correct”

Most developers start with this:

new Date()

It prints a date and time that looks correct, so we assume everything
underneath is local and intuitive.

That assumption is where many bugs begin.

JavaScript dates are not stored as local time.

Internally, they are stored as:

Milliseconds since January 1, 1970 (UTC)

Local time, timezone, and formatting are applied only when the date is
read or displayed.

This sounds like a small detail.
In real apps, it isn’t.

What JavaScript is actually doing

A useful mental model is this:

JavaScript stores one number
That number represents a moment in UTC
Local time is calculated only at display or formatting time

For example:

new Date("2026-02-10T09:00:00")

This does not mean “9am in my timezone”.

It means “9am UTC, converted to the user’s local timezone”.

If your app does not control that context explicitly, time slowly drifts.

The three most common time mistakes

1. Assuming `Date()` is local internally

Date behaves like a local clock, but it is not one.

It is a UTC timestamp with a local view layered on top.

This becomes a problem when:

users are in different timezones
servers run in UTC
background jobs don’t share locale information

2. Mixing server time and client time

A very common pattern:

server schedules something
client displays or adjusts it
background job runs later

If these layers don’t agree on what “now” means, reminders drift.

This is especially dangerous for:

recurring schedules
weekly reminders
“tomorrow at 9am” logic

3. Generating dates without context

Any logic that generates dates needs to know:

today’s date
the user’s timezone
daylight saving rules

Without this context, it’s easy to generate reminders:

in the past
on the wrong day
in the wrong year

Why this gets worse in PWAs

These problems become much more visible in Progressive Web Apps.

Browsers are not designed to guarantee precise scheduling.
They optimize for:

battery life
performance
security

As a result:

background execution is delayed
service workers wake unpredictably
scheduled logic runs in time windows, not exact moments

I ran into this while building a productivity app where reminders and
check-ins were core features.

Notifications worked.
Nothing crashed.
But timing was unreliable.

I wrote about that experience here:

When Notifications Matter, PWAs Start to Show Their Limits

https://dev.to/nishchaldev/when-notifications-matter-pwas-start-to-show-their-limits-5ebl

That post explains where things broke.
This post explains why.

How mature apps avoid time bugs

Once I looked at how established reminder apps work, a clear pattern
emerged.

One clear definition of “now”

There is exactly one source of truth for current time:

based on the device timezone
or an explicit user setting

No guessing.
No hidden defaults.

Store in UTC, schedule in local time

This is the most important rule.

Store timestamps in UTC
Convert to local time for display
Schedule alarms using local context

This avoids:

daylight saving bugs
timezone drift
unexpected early or late triggers

Let the OS handle scheduling

On native platforms, reminders are scheduled using system services.

The operating system:

reschedules after reboots
adjusts for timezone changes
guarantees delivery timing

JavaScript logic does not need to stay alive.

The shift that fixed my app

After understanding these patterns, I changed the architecture:

the web app handles dashboards and planning
the native layer handles scheduling and notifications
the backend stores everything in UTC
time context is always explicit

The same product logic runs everywhere, but time-sensitive
responsibilities live where they belong.

The app is still evolving, but the difference is noticeable.

Live app:

https://wio-dev.vercel.app

A simple rule that helps

If you remember only one thing, remember this:

Time is not a utility. It’s a product feature.

If your app depends on time being correct:

model it deliberately
pass context explicitly
let the platform handle scheduling

Closing thought

JavaScript dates are not broken.
Browsers are not broken.

Most time bugs come from assumptions that feel reasonable until real
users and real schedules expose them.

Once your mental model matches how time actually works, things become
much simpler.

A question for you

Have you run into confusing date or timezone bugs?
How are you handling reminders or schedules today?
Did this explanation match what you’ve seen in practice?

I’d genuinely love to hear how others are dealing with this.

When notifications matter, PWAs start to show their limits

nishchal singh — Sat, 07 Feb 2026 08:37:57 +0000

I was getting notifications at 3am.

Users were confused.

I hadn’t changed anything.

That’s when I realized something uncomfortable:

PWAs don’t really understand time the way we expect them to.

Nothing was “broken” in the obvious sense.

Reminders worked. Notifications appeared. Logs looked fine.

But for a productivity app — where reminders and check-ins are the product —

“mostly works” isn’t good enough.

This post is about what went wrong, why it wasn’t actually a bug, and why I eventually stopped relying on a pure PWA setup for time-critical notifications.

When PWAs work great (and when they don’t)

If your app needs:

in-app banners
occasional push notifications
background sync when possible

PWAs are an excellent choice.

They’re fast to build, easy to ship, and good enough for many products.

But reminders are different.

A reminder isn’t just a notification.

It’s a promise about time.

And time is where PWAs start to show their limits.

How PWA notifications really behave

When a PWA is open:

JavaScript is running
the user’s local time is known
scheduling logic is predictable

Things feel solid.

The problems start once the app is closed or backgrounded.

At that point:

the browser decides when background work runs
service workers wake up only under certain conditions
push delivery is best-effort
timing happens in windows, not exact moments

A “scheduled” notification often looks like this:

a backend job checks reminder time
timezone logic runs on the server
a web push is sent
the browser decides when (or if) to wake the service worker
the OS eventually shows the notification

Each step makes sense on its own.

Together, they introduce uncertainty.

This isn’t bad engineering.

It’s how browsers are designed.

Browsers optimize for battery life, performance, and security —

not precise scheduling guarantees.

Where things actually broke for me

At first, I assumed this was just a PWA limitation.

Then I wrapped the app with a native Android container and refactored the notification flow.

Some issues still showed up.

That’s when it became clear:

Notification reliability isn’t just about platform choice.

It’s also about how your app understands time itself.

Looking at how mature reminder apps work made the gaps obvious.

What real reminder apps get right

Apps like Google Calendar, TickTick, and Any.do all follow the same principles.

One clear definition of “now”

There is a single authoritative source of current time —

based on device timezone or an explicit user setting.

No guessing.

No hidden defaults.

Store in UTC, schedule in local time

Events are stored in UTC.

They’re converted to local time only for display and scheduling.

This avoids slow, painful bugs around daylight saving and timezone changes.

OS-level scheduling

Reminders are scheduled using system services (for example, AlarmManager on Android).

They’re automatically rescheduled when:

the device restarts
the timezone changes
daylight saving rules shift

The OS owns delivery — not JavaScript.

No dates without context

Any AI planner or automation that generates dates is explicitly told:

“Today is YYYY-MM-DD in this timezone.”

Without this, it’s surprisingly easy to generate reminders in the past or wrong year without noticing.

The real issues in my app

Once I stepped back, the problems were surprisingly basic:

timezone defaulting to UTC instead of user locale
AI planner not receiving current date and timezone explicitly
weekly reminders drifting due to timezone conversion
limited control over notification channels and sounds

These aren’t exotic bugs.

They’re the kind that appear only after real users and real time collide.

Why Android behaves more predictably

On Android, the mental model is simpler:

the app schedules the reminder locally
the OS owns the timing
the notification fires when expected

Even if:

the app is closed
the process is killed
the device restarts

Notifications are first-class system features.

That’s why:

sound and vibration are consistent
notification channels behave correctly
widgets are possible
background behavior is predictable

This isn’t about Android being “better”.

It’s about using the platform for what it was designed to do.

The setup that finally made sense

For this app, reminders and check-ins aren’t optional.

They are the product.

So the architecture that aligned best was:

Web app (desktop)

dashboards
insights
planning and review

Android app (Capacitor wrapper)

native scheduling
OS-level notifications
background reliability

Same backend.

Same database.

Same product logic.

Different delivery mechanisms — matched to platform strengths.

A simple rule of thumb

If notifications are a nice-to-have → PWAs are usually fine
If notifications are a core promise → let the OS handle timing

That distinction would have saved me weeks.

Final thought

PWAs aren’t unreliable.

They’re just not designed to guarantee time.

Native platforms are.

Once you align product expectations with what a platform can realistically promise, a lot of confusion — and frustration — disappears.

Quick question for you

Have you faced random notification timings in PWAs?
How are you handling scheduled reminders today?
Would you still choose a PWA if notifications were critical?

I’m genuinely curious how others are solving this.

Live app (still evolving):

👉 https://wio-dev.vercel.app

Object Cloning in Javascript

nishchal singh — Fri, 01 Mar 2024 05:43:13 +0000

While coding in Javascript have you ever encountered a situation where you needed to copy an object? and when you try to copy an object, you face some issues like all of the properties are not cloned, or when changing the copied object somehow the original object is changed, leaving you without the desired results. Well, In this article we'll explore some simple solutions to these issues.

First thing that came to your mind is that why not simply use 🟰 to copy objects, but it'll not work b'coz Javascript objects are reference type values. worry not, there are 3 basic ways of object cloning:

const originalObject = { name: 'John', age: 30 };

// Using Spread Operator (...)
const spread_Cloned = { ...originalObject };

// Using Object.assign() Method
const assign_Cloned = Object.assign({}, originalObject);

// Using JSON.stringify() and JSON.parse() 
const cloned_JSON = JSON.parse(JSON.stringify(originalObject));

console.log(spread_Cloned); // { name: 'John', age: 30 }
console.log(assign_Cloned); // { name: 'John', age: 30 }
console.log(cloned_JSON); // { name: 'John', age: 30 }

Introduction

If you're dealing with tricky data setups, making exact copies, or just want to keep things from changing unexpectedly, copying objects can be super helpful in JavaScript. This article is all about diving into object cloning in JavaScript. We'll check out different ways to do it and figure out when and why it's important. By the time you finish reading, you'll totally get how to clone objects and be ready to use it in your own coding projects.

Shallow Clone vs Deep Clone

When you shallow clone something in JavaScript, you're basically making a copy that only goes skin-deep. It means you get a new object with the same basic stuff as the original, but if those basic things include other objects, those aren't copied – they're just referenced. Now, deep cloning is like making a photocopy of everything. You get a brand-new object where every little thing, even the stuff inside other stuff, gets copied over completely. So, you end up with a totally separate copy of everything from the original.

Techniques for Object Cloning

Using Spread Operator (...)

The spread operator in JavaScript is a concise and efficient way to clone objects. It allows us to create a copy of an object, including all its enumerable properties, into a new object.

const originalObject = { name: 'John', age: 30 };
const clonedObject = { ...originalObject };

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Very simple syntax
Supports cloning both Shallow and moderately nested objects

Limitations:

Cannot handle deeply nested objects
Does not clone non-enumerable properties or methods

Using Object.assign() Method

The Object.assign() method is another powerful technique to clone objects. It copies the values of all enumerable properties from one or more source objects into a target object, returning the target object.

const originalObject = { name: 'John', age: 30 };
const clonedObject = { ...originalObject };

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Handles cloning of non-enumerable properties and methods
Supports cloning moderately nested objects

Limitations:

Cannot clone deeply nested objects directly
Overwrites properties if they already exist in the target object

Using JSON.stringify() and JSON.parse()

The combination of JSON.stringify() and JSON.parse() methods can be used as a workaround for cloning complex objects. By converting the object to a JSON string and then parsing it back into an object, we can achieve a Deep Clone of the original object.

const originalObject = { name: 'John', age: 30 };
const clonedObject = JSON.parse(JSON.stringify(originalObject));

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Supports cloning deeply nested objects
Can be used to clone objects with circular references

Limitations:

Does not preserve non-enumerable properties or methods
May not preserve certain data types (e.g., dates, regular expressions) during cloning
.

Using Third-party Library

Lodash is a popular JavaScript utility library that provides a powerful method called cloneDeep() for object cloning. It performs a deep copy of the entire object hierarchy, ensuring accurate replication of the original object's structure.

const originalObject = { name: 'John', age: 30 };
const clonedObject = _.cloneDeep(originalObject);

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Can handle cloning of any level of object nesting
Preserves non-enumerable properties and methods

Limitations:

Adds a dependency on an external library (Lodash)
May have performance implications for large objects due to deep copying

If you don't want to use any third-party library, there is an alternate solution: using a custom deep cloning function we'll discuss it further in this article. Both have their advantages and limitations.

Shallow Cloning

Shallow cloning is the simplest form of object cloning. It creates a new object with the same top-level properties as the original object. However, if those properties are themselves objects, they are still references to the original objects. Shallow cloning is a quick and easy way to duplicate objects when there's no need to clone nested objects.

Shallow Clone Example:

const originalObject = {
  name: 'John',
  age: 25,
  hobbies: ['reading', 'swimming'],
};

const clonedObject = { ...originalObject };

In this example, the spread operator (...) creates a shallow clone of originalObject. Although clonedObject appears to be an identical copy, modifying the hobbies property in either object will affect both, as they still share a reference to the same array.

We can fix this issue by Deep Cloning.

Deep Cloning

Deep cloning is a more thorough form of object cloning. It creates a new object and recursively clones all nested properties and their descendants, ensuring each object is an independent copy. Deep cloning is indispensable when working with complex data structures and avoiding unintended side effects.

Using JSON.stringify() and JSON.parse():

//Deep Clone Using JSON.stringify() and JSON.parse()
const originalObject = {
  name: "John",
  age: 30,

  // Nested object
  address: {
    city: "New York",
    state: "NY",
  },

  // Method
  doAction: function () {
    console.log(this.name + " is walking in " + this.address.city);
  },
};
const clonedObject = JSON.parse(JSON.stringify(originalObject));

console.log(clonedObject);
 // { name: 'John', age: 30, address: { city: 'New York', state: 'NY' } }

As we can see in the above example we are losing our data, the method "doAction" is not cloned b'coz it does not preserve non-enumerable properties or methods. The solution for this issue is given below.

Using Custom Recursive Function:

// Deep Clone Using Custom Recursive Function
// Custom Recursive Function 
function deepClone(obj, visited = new WeakMap()) {
  // Handle non-object types and null
  if (obj === null || typeof obj !== 'object') {
    return obj;
  }

  // Handle circular references
  if (visited.has(obj)) {
    return visited.get(obj);
  }

  // Handle dates
  if (obj instanceof Date) {
    return new Date(obj.getTime());
  }

  // Handle regular expressions
  if (obj instanceof RegExp) {
    return new RegExp(obj);
  }

  // Handle arrays
  if (Array.isArray(obj)) {
    const cloneArray = [];
    visited.set(obj, cloneArray);
    obj.forEach((item, index) => {
      cloneArray[index] = deepClone(item, visited);
    });
    return cloneArray;
  }

  // Handle objects
  const cloneObj = {};
  visited.set(obj, cloneObj);
  for (let key in obj) {
    if (Object.prototype.hasOwnProperty.call(obj, key)) {
      cloneObj[key] = deepClone(obj[key], visited);
    }
  }
  return cloneObj;
}

const clonedObject = deepClone(originalObject);
console.log(clonedObject); /*{
  name: 'John',
  age: 30,
  address: { city: 'New York', state: 'NY' },
  doAction: [Function: doAction]
}*/

console.log(clonedObject.doAction()); // John is walking in New York

In this example, deepClone is a recursive function that clones all properties and nested objects of originalObject. The resulting clonedObject is a deep copy, ensuring no changes made to original one and no object will impact the other.

We use a WeakMap to keep track of visited objects to handle circular references.
We add support for cloning Date objects and RegExp objects.
We handle cloning of arrays and objects separately to ensure correct cloning and handling of circular references.
We use Object.prototype.hasOwnProperty.call(obj, key) to ensure that properties from the object's prototype chain are not mistakenly cloned.

This deepClone function can handle a wider range of data types and scenarios.

Let's see another example of 'deepClone' function with different data types:

// Define an object with various data types including arrays, objects, dates, and regular expressions
const originalObject = {
  string: "Hello",
  number: 123,
  boolean: true,
  array: [1, 2, 3],
  object: { a: 1, b: 2 },
  date: new Date(),
  regexp: /test/g,
};

// Add circular reference
originalObject.circular = originalObject;

// Clone the original object
const clonedObject = deepClone(originalObject);

// Modify the cloned object
clonedObject.string = "Modified";
clonedObject.number = 456;
clonedObject.array.push(4);
clonedObject.object.c = 3;

// Log both original and cloned objects
console.log("Original Object:", originalObject);
/*Original Object: <ref *1> {
  string: 'Hello',
  number: 123,
  boolean: true,
  array: [ 1, 2, 3 ],
  object: { a: 1, b: 2 },
  date: 2024-02-23T13:18:38.521Z,
  regexp: /test/g,
  circular: [Circular *1]
}*/
console.log("Cloned Object:", clonedObject);
/*Cloned Object: <ref *1> {
  string: 'Modified',
  number: 456,
  boolean: true,
  array: [ 1, 2, 3, 4 ],
  object: { a: 1, b: 2, c: 3 },
  date: 2024-02-23T13:18:38.521Z,
  regexp: /test/g,
  circular: [Circular *1]
}*/

in this example:

We define an originalObject containing various data types including arrays, objects, dates, and regular expressions.
We add a circular reference to the originalObject.
We then clone the originalObject using the deepClone function.
We modify some properties of the cloned object to demonstrate
that the original object remains unaffected by the modifications to the clone.
Finally, we log both the original and cloned objects to see the differences.

The deepClone function has several advantages and limitations:

Advantages:

Deep Cloning: The function can recursively clone nested objects and arrays, ensuring a deep copy of the original object.
Support for Various Data Types: It supports cloning of various data types including objects, arrays, dates, and regular expressions, making it versatile for different use cases.
Handling Circular References: It can handle circular references gracefully by keeping track of visited objects using a WeakMap, preventing infinite recursion.
Maintains Object Structure: It maintains the structure of the original object, including nested objects and arrays, ensuring the cloned object has the same structure.
Flexible and Customizable: It can be extended to support additional data types or custom cloning logic based on specific requirements.

Limitations:

Performance: Deep cloning can be computationally expensive, especially for large and deeply nested objects, potentially leading to performance issues.
Prototype Chain: It does not preserve the prototype chain of objects. Cloned objects will lose their original prototype chain and inherit from Object.prototype.
Non-Clonable Properties: Certain properties like non-enumerable properties or properties with getters/setters may not be cloned accurately.
External References: If the original object contains references to external resources or mutable shared state, the cloned object will still reference the same external resources, potentially leading to unintended side effects.
Memory Consumption: The use of a WeakMap for handling circular references may consume additional memory, especially for large datasets with many circular references.

Overall, while the deepClone function provides a robust solution for deep copying objects, it's important to be aware of its limitations and potential impact on performance and memory usage, especially in scenarios involving large or complex data structures.

Conclusion

Remember, when cloning objects, it's crucial to choose the appropriate method based on your specific needs. Whether you opt for native JavaScript techniques or leverage external libraries like Lodash or Immer, object cloning is a valuable tool for maintaining data integrity and preventing unintended side effects.

So, the next time you find yourself needing to duplicate an object in JavaScript, don't go down the path of manual copying and mutation. Instead, harness the power of object cloning and unlock a world of possibilities.

"Object cloning in JavaScript is the key to maintaining data integrity and avoiding unintended side effects."

Overview of ReactJs

nishchal singh — Tue, 12 Dec 2023 14:14:59 +0000

Whenever the development community talks about modern web development stacks, the word "ReactJS" is often mentioned. It's one of the widely used tech stacks for web development, In this article, we'll take an overview of ReactJS.

What is ReactJs?

ReactJS, or simply React, is like a superhero or supertool for building websites and web applications. It's a special set of tools and rules that helps people create websites that are not only really cool but also super fast and easy to work with.

React is a JavaScript-based front-end library used for UI(user interface) development. It's used to create modular user interfaces and promotes the development of reusable UI components that display dynamic data. React is often used to build single-page applications (SPAs).

Concept of ReactJS

his is Hashnode's homepage as we can see here a react application is made from independent components that together make a whole web application. The search bar in the top header is a reusable component. the same search bar component is used in the other sections of this app.

Key concepts and principles of ReactJS include:

Component-Based Architecture: React is built around the idea of breaking down user interfaces into reusable, self-contained components. These components can range from simple elements like buttons or form inputs to complex parts of the user interface like navigation bars or entire pages. By building UIs as components, development becomes modular, maintainable, and scalable.

Virtual DOM (Document Object Model): React introduced the concept of a Virtual DOM which is like a lightweight copy of the actual DOM. virtual DOM is an abstract representation of the actual DOM in the browser. When data in a React application changes, React doesn't directly manipulate the real DOM. Instead, it creates a virtual representation of the changes and efficiently updates only the parts of the real DOM that need to change. This approach minimizes browser reflows and enhances performance.

The image below is a visual representation of the concept of the virtual DOM:

Unidirectional Data Flow: React follows a unidirectional data flow, where data moves in one direction, usually from parent components to child components. Child components cannot send data back to their parent components. This design minimizes errors and gives us greater control over our code.

As shown in the diagram below, data can only flow from top to bottom:

Component Lifecycle: React components have a lifecycle that includes various methods such as componentDidMount, componentDidUpdate, and componentWillUnmount. These lifecycle methods allow developers to hook into different stages of a component's existence and perform actions like data fetching, DOM manipulation, or cleanup.

State in React: In ReactJS, "state" refers to a built-in feature that allows you to manage and store data within a component. State represents the internal data of a component that can change during the component's lifecycle, and when it does change, React will automatically re-render the component to reflect the updated state.

State acts as a storage space for data essential for a component's functioning. It's versatile, capable of holding different data types like numbers, strings, arrays, or objects. Unlike props, which are unchangeable and flow from parent to child components, state is changeable. Components have the power to modify their own state through React's setState method.

Reactivity: React encourages a reactive approach to UI development. When the state or props of a component change, React automatically re-renders the component to reflect those changes. This reactivity simplifies UI updates and ensures that the UI always matches the application's data.

State Management: React components can effectively handle their internal state using either the useState hook for functional components or class-based state for class components. These approaches allow components to store and update data within themselves.

For more intricate applications, developers often turn to state management libraries like Redux or Mobx. These libraries centralize and manage state across the entire application, making it easier to handle complex data interactions.

For instance, consider a web application with dynamic notification functionality. State management ensures that notifications can be added, removed, and displayed in real-time without the need for complex manual updates. Similarly, in an online shopping cart, managing the dynamic count of items and their state helps ensure a seamless and responsive user experience.

JSX (JavaScript XML): JSX, which stands for JavaScript XML, is a powerful feature in React. It's like a special language that React developers use to describe how a component should look. Imagine it as a blend of HTML and JavaScript that makes building user interfaces more intuitive.

With JSX, you can write your user interface code in a way that closely resembles HTML. This not only makes it easier to understand but also helps you visualize your UI components. However, under the hood, JSX gets converted into regular JavaScript using tools like Babel before it's shown in the browser.

One of the cool things about JSX is that you can embed JavaScript expressions within curly braces {}. This means you can include dynamic content, variables, and calculations right alongside your JSX code. It's a flexible way to create dynamic and interactive user interfaces in React.

import React from 'react';

function Greeting(props) {
  const name = props.name;
  const isLoggedIn = props.isLoggedIn;

  // Define a JavaScript function to conditionally render a greeting message
  function getGreeting(name) {
    if (isLoggedIn) {
      return <p>Hello, {name}!</p>;
    } else {
      return <p>Please log in.</p>;
    }
  }
  return (
    <div>
      {/* Embed JavaScript expression to render the greeting message */}
      {getGreeting(name)}
    </div>
  );
}
export default Greeting;

Community and Ecosystem: React has a vast and active community, resulting in a rich ecosystem of third-party libraries, tools, and extensions. These resources make it easier for developers to build feature-rich and performant applications.

How Does ReactJS Work?
ReactJS works by utilizing a component-based architecture to build user interfaces efficiently. It uses a Virtual DOM to optimize updates, enforces a unidirectional data flow for predictable behavior, and allows developers to define UI components using JSX, which is transpiled into JavaScript. React updates the actual DOM efficiently, making it ideal for creating dynamic and interactive web applications.

Conclusion
ReactJS stands as a powerful and pivotal force in modern web development. Its component-based architecture, Virtual DOM, and unidirectional data flow provide developers with a robust toolkit to create dynamic and responsive user interfaces. React's flexibility, combined with a thriving community and extensive ecosystem, makes it a top choice for building web applications that are not only efficient and maintainable but also user-friendly. As we've explored in this overview, ReactJS empowers developers to bring their web projects to life with elegance and precision, setting new standards for web development in the digital age. Whether you're a seasoned developer or just beginning your journey, ReactJS remains a technology worth exploring and mastering.

DEV Community: nishchal singh

Why Date and Time Bugs Happen in JavaScript (And How Apps Actually Get It Right)

If you’ve ever seen reminders fire early, late, or on the wrong day,

The illusion: “I used Date(), so time should be correct”

What JavaScript is actually doing

The three most common time mistakes

1. Assuming Date() is local internally

2. Mixing server time and client time

3. Generating dates without context

Why this gets worse in PWAs

How mature apps avoid time bugs

One clear definition of “now”

Store in UTC, schedule in local time

Let the OS handle scheduling

The shift that fixed my app

A simple rule that helps

Closing thought

A question for you

When notifications matter, PWAs start to show their limits

I was getting notifications at 3am.

When PWAs work great (and when they don’t)

How PWA notifications really behave

Where things actually broke for me

What real reminder apps get right

One clear definition of “now”

Store in UTC, schedule in local time

OS-level scheduling

No dates without context

The real issues in my app

Why Android behaves more predictably

The setup that finally made sense

Web app (desktop)

Android app (Capacitor wrapper)

A simple rule of thumb

Final thought

Quick question for you

Object Cloning in Javascript

Introduction

Shallow Clone vs Deep Clone

Techniques for Object Cloning

Using Spread Operator (...)

Using Object.assign() Method

Using JSON.stringify() and JSON.parse()

Using Third-party Library

Shallow Cloning

Deep Cloning

Using JSON.stringify() and JSON.parse():

Using Custom Recursive Function:

The deepClone function has several advantages and limitations:

Conclusion

Overview of ReactJs

The illusion: “I used `Date()`, so time should be correct”

1. Assuming `Date()` is local internally