Time and Data Conversion

Choose the right conversion model

A storage amount, an elapsed duration and a timestamp describe different things. Choose the unit system or time model before calculating: decimal and binary prefixes differ, calendar days can change length, and a local clock label may identify more than one instant.

This guide includes worked examples, two diagrams, practice answers and links that open the converters with the example inputs selected. Historical timezone examples use explicit dates in 2024 so their assumptions remain visible. For a future meeting, use the actual date and current timezone rules.

1. Data quantity: identify bits or bytes, then decimal or binary prefixes. Converting the label preserves the underlying amount of information.
2. Elapsed duration: identify a measured interval. Hours and minutes can be converted with fixed factors, but a decimal-hour number is not a clock-style hours-and-minutes string.
3. Timestamp: identify one instant, the epoch and the unit of its numeric counter. For a formatted date-time, retain an explicit UTC indicator or offset.
4. Local calendar time: retain the date and named timezone. Resolve missing or repeated clock times deliberately; a fixed offset alone does not describe all future rules for a location.

Do not fix an implausible answer by guessing a different unit. Return to the source label or API contract. The Common Unit Conversions guide explains the same dimensional method for physical quantities; this article adds the prefix and calendar conventions that digital work requires.

Decimal versus binary storage units

Decimal prefixes use powers of a thousand. Binary prefixes use powers of two and include an “i” in the symbol. Capitalization matters: the byte symbol is uppercase B, while bit-based rates are often written with lowercase b or the word bit. Use the complete label when a source uses an ambiguous abbreviation.

Definitions: NIST binary prefixes and decimal comparisons.

Example: one gigabyte expressed in gibibytes

1. Normalize the decimal amount to bytes: $1\,\mathrm{GB}=1{,}000{,}000{,}000\,\mathrm B$.
2. Use the binary unit size: $1\,\mathrm{GiB}=1{,}073{,}741{,}824\,\mathrm B$.
3. Divide the byte amount by the bytes per gibibyte.$$1\,\mathrm{GB}=\frac{10^9}{2^{30}}\,\mathrm{GiB}\approx0.931322575\,\mathrm{GiB}$$

The reverse conversion is $1\,\mathrm{GiB}=1.073741824\,\mathrm{GB}$. The unit-label change does not consume storage. Filesystem metadata, reserved space and partitions are separate reasons that usable capacity can be smaller than a device's nominal byte capacity.

Bits, bytes and ideal transfer time

A data amount and a data rate are not interchangeable. A rate has a time denominator. Convert bits and bytes consistently, then divide the amount by a rate in matching units. This provides an ideal duration only if that rate is sustained for the entire transfer.

Example: an ideal file download

1. Assume a decimal file size of $500\,\mathrm{MB}$ and a sustained payload rate of $100\,\mathrm{Mbit/s}$.
2. Convert the file amount: $500\,\mathrm{MB}=4000\,\mathrm{Mbit}$.
3. Divide amount by rate: $t=4000\,\mathrm{Mbit}/(100\,\mathrm{Mbit/s})=40\,\mathrm s$.

Advertised connection speed is not a promise of that sustained payload rate. Protocol overhead, congestion, storage throughput and other traffic can increase the time. Compression can change the transmitted amount. State those assumptions before treating the estimate as a schedule.

This link compares data amounts. The per-second rate relationship above uses the same bit-to-byte factor; the storage tool is not a live bandwidth test.

Elapsed duration is not calendar arithmetic

For fixed-duration conversion, one day means exactly $24\,\mathrm h=86400\,\mathrm s$. This definition does not claim that every pair of consecutive local midnights is that far apart. A calendar month also has no single fixed number of days. Average Gregorian month and year options are averages, not calendar deadlines.

Example: combine hours and minutes

1. Identify the separate components: $2\,\mathrm h$ and $30\,\mathrm{min}$.
2. Convert both components to seconds.$$t=2(3600)\,\mathrm s+30(60)\,\mathrm s=9000\,\mathrm s$$
3. Check in hours: $9000/3600=2.5$. The result is $2.5\,\mathrm h$, not a decimal formed by joining the hour and minute digits.

Likewise, $1.5\,\mathrm h=90\,\mathrm{min}$. Decimal $1.30\,\mathrm h$ is $78\,\mathrm{min}$, while the timer string 01:30:00 means one hour and thirty minutes. Always distinguish decimal quantities from timer syntax.

Unix seconds and JavaScript milliseconds

A Unix-style timestamp identifies an instant using a numeric counter relative to the epoch, 1970-01-01T00:00:00Z. Unix timestamps commonly use seconds; JavaScript Date stores milliseconds. Ordinary Unix/ECMAScript time does not count historical leap seconds as extra increments, so it should not be described as an uninterrupted SI-second clock across those insertions.

Let $t_s$ and $t_{\mathrm{ms}}$ be the numerical counters for the same instant in seconds and milliseconds. Changing the counter unit changes the number, not the instant.

Example: midnight at the start of 2024

1. Start with the UTC instant 2024-01-01T00:00:00Z.
2. Its Unix seconds counter is $t_s=1{,}704{,}067{,}200$. Multiply by $1000$ to obtain $t_{\mathrm{ms}}=1{,}704{,}067{,}200{,}000$.
3. Choose the matching input unit before decoding. Both correctly labeled inputs return the same UTC date-time. Interpreting the seconds number as milliseconds instead places it near the beginning of 1970.

Zero identifies the epoch; $-1$ Unix second identifies the preceding second. Digit counts alone cannot reliably infer the unit, especially for small, negative or fractional values. A date-time string without a UTC indicator or offset can be interpreted differently by different environments. For fractional values, check whether the receiving system preserves them, rounds them or truncates them.

The offset-qualified input above subtracts its four-hour offset to resolve the same UTC instant. A numeric offset is sufficient for that instant, but it is not a complete timezone rule for future recurrences. See ECMAScript time values and RFC 3339 timestamp conventions.

Convert a meeting using a date and named zones

IANA names such as America/New_York, Europe/London and Asia/Dubai identify location-based rule sets. An abbreviation alone can be ambiguous, and a fixed offset copied from today can be wrong for another date.

Example: a historical January meeting

1. Enter January 15, 2024, at 09:00 in New York. On that date, its offset was UTC−05:00.
2. Resolve the instant as 2024-01-15T14:00:00Z.
3. Display that same instant in the other zones: London was 14:00 and Dubai was 18:00, both on January 15.

The time conversion does not guarantee a convenient meeting. Dubai's time is after a typical afternoon work window, and working hours, holidays and leave need their own checks. The linked planner checks configured weekly work windows; it does not infer holidays or calendar bookings.

For a recurring local meeting, retain its local time, zone and recurrence rule. Resolving each occurrence is different from repeating one stored UTC offset forever. Update the browser or runtime timezone data and reconfirm future schedules when regional rules change. IANA explains how the database is maintained.

Daylight saving gaps and repeated times

Spring: a clock label that never occurs

In New York on March 10, 2024, the local clock jumped from the end of the 01:00 hour to 03:00. The local time 02:30 did not exist. A strict converter should reject that input or require an explicit adjustment policy instead of silently pretending it is an ordinary instant.

The interval from local 01:30 to 03:30 was only $1\,\mathrm h$ of elapsed time: the corresponding UTC instants were 06:30 and 07:30. Consecutive local midnights bounding that calendar day were twenty-three hours apart.

Autumn: one label with two possible instants

On November 3, 2024, New York's 01:30 occurred twice. The earlier occurrence was 2024-11-03T05:30:00Z; the later one was 2024-11-03T06:30:00Z. They were an hour apart even though the local date and clock label matched. That local calendar day spanned twenty-five elapsed hours.

Historical dates: US Naval Observatory, 2024 daylight saving time. These one-hour transitions are examples, not a rule for every zone or historical clock change.

Practice with worked answers

Identify the model before doing the arithmetic. Open each answer after deciding which unit definition or time reference applies.

Time and data conversion questions

Sources and example assumptions

The arithmetic examples use exact unit definitions and nominal input values. Timezone examples identify a historical date and zone; they are checked against the runtime's named-zone resolver and independent offset arithmetic. Timestamp values use the ordinary Unix/ECMAScript model, with no leap-second label input assumed.

• NIST: binary prefixes

  Decimal and binary prefix definitions, byte and bit relationships.

• IANA: Time Zone Database

  Named-zone history, changing civil-time rules and software updates.

• US Naval Observatory: 2024 daylight saving dates

  The historical March and November transition dates used in the New York examples.

• ECMAScript: time values and time range

  JavaScript millisecond timestamps and the model excluding leap seconds.

• MDN: JavaScript Date

  Date storage, UTC versus local views, offset changes and timestamp parsing.

• RFC 3339: Internet timestamps

  Offset-qualified date-time strings and why an unqualified local time is incomplete.