top | item 44886010

(no title)

codingminds | 6 months ago

Explanation from https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/EX...

> It is intended for use as a factory default, to clearly indicate an unconfigured system rather than one that is intentionally configured to run on UTC.

discuss

order

xp84|6 months ago

> unconfigured system

Does this mean:

1. a system which believes it has an accurate idea what the current UTC time is, but doesn't know where it is on Earth (or where its operator conceptually wants it to pretend it is)?

2. Or a system which has had its clock set manually, but its TZ has never been set (therefore it has no idea what the UTC time is, and therefore cannot reliably generate or store a valid time with offset.

3. Or a system which knows both its clock and its TZ have never been set?

For the first one, it seems silly, since as long as you're recording correct timestamps, fixing the display timezone later is easy and nondestructive. For 2 it seems like the OS should require setting TZ to set a time. For 3, I suppose this is actually mildly useful, since it's easy for an OS to detect if you have inited the RTC from its original starting point, and specially flagging datetimes stored while it's in that state could help to clean them up later when the correct time is known.

jgalt212|6 months ago

Sort of like Django defaulting to Chicago time.

echoangle|6 months ago

For me, the latest django defaults to "TIME_ZONE = 'UTC'" in the settings.py.

wodenokoto|6 months ago

So its a valid time zone used to indicate that the clock is off?

jon-wood|6 months ago

A valid time zone used to indicate that the clock isn't configured yet. It may be accurate to UTC, but the offset shouldn't be trusted.

DaiPlusPlus|6 months ago

> to clearly indicate an unconfigured system rather than one that is intentionally configured to run on UTC

...everything should be based on UTC though!

defrost|6 months ago

Tinder dates and market moves, maybe.

Real time scientific, physics, and engineering data acquisition and processing applications? Goodness no.

Certainly nothing that might want to generate a waypoint heading update via a division of elapsed time. Not with those random UTC leap seconds that can go either way (although, until now, they've all fallen in one direction).

There's a reason serious real time real world data processing goes with epoch based time, lapsed time since <mark>, it has the nice feature of being monotonically increasing.

rtpg|6 months ago

There’s an argument to say that the datetimes should be stored in UTC. But if a user wants to see datetimes in their local time zone (a config or w/e), then you gotta hold onto a time zone!

Not really defending the Factory timezone but I do think we gotta think about timezones

eirikbakke|6 months ago

A subscription will renew at 2025-08-16 04:04Z, and the billing system must send an email to the user reminding them of this. What date do you show in the email?

A meeting happens every Tuesday at 9am, starting February 18, 2025. What time does the calendar show once DST kicks in?