How do you like your dates and times localized?

[jeffgdotorg]

Hi folks, the NetBox maintainers are working through some changes in 4.0 to the way we handle the localization of dates and times. The main driver here is that Django 5.0 introduced localization of all dates and numbers by default, according to the locale setting provided by the user's browser. This means that we expect NetBox 4.0 to ship with all dates and times represented the same way they appear by default in, say, your local calendar app or in a spreadsheet cell with its format type set to Date. (As an aside, we're aware that that's not what happens in 4.0-b1; set that aside for the moment.)

We know local formatting is is sometimes what users want, but we're curious how you feel about the matter. Do you prefer, for example, ISO-8601 format in some or all places?

I'm leaving this intentionally open-ended rather than opening a poll so that we can get a better feel for the range of preferences. Thanks in advance for chiming in!

[jsenecal]

I do not have a STRONG opinion on this but Its is important for us that dates and times make sense. Here in East Canada we write dates in DD/MM/YYYY or YYYY-MM-DD, which is very different than the american way.

So if a "standard" one is to be pushed, make it an international one like the ISO-8601 you mentioned.

On a side note, keeping track of time zones should be considered when displaying datetimes. The server may have stored a datetime in a different timezone than the end-user reading the information.

[jeffgdotorg]

Full ack. I'm committed to making sure that we do not force our weird middle-endian date format upon our users in the rest of the world.

[jhammond-git]

Making them match what the user expects to see makes the most sense to me (locale). For a fallback, you can't go wrong with a standard, given the audience.

[ianspray]

I work with devices across multiple timezones reporting health info back to a single netbox, and use the Journal entries for the units to log pre-fail issues they find with themselves. I always use UTC for all systems so I can better correlate potential issues without worrying about the detail of local timezones/summer time, so whilst I do appreciate the "local view" I would also greatly value the ability to force all times to UTC regardless of what my browser says. Having this as a view option on a page that display times and not buried in my personal account preferences would be very much appreciated.

Having local time views is also useful (issues in the past between one site on summer time and the other that doesn't doesn't have any concept of summer time), and I also massively support jsenecal's statement about time formatting: I would always prefer a formal non-locale specific standard like ISO-8601 over a country-specific way.

[markkuleinio]

Whenever any IT system gives me the option, I will always select "yyyy-mm-dd hh:mm:ss tzoffset" if possible. That's clear for also anyone that gets to see the occasional copy-paste or screenshot, and is sortable. And without the "T" (between date and time) it is very clear to read and understand.

Whenever any IT system changes the localized output based on my browser settings (which I may or may not have set myself intentionally), most of the time either the autodetection misbehaves or the produced output is outright incorrect in Finnish. Thus most of those cases leads me to change the app settings manually.

[tyler-8]

ISO-8601 with UTC offset would be my preference. IMO the 'perfect' balance is always ISO-8601 format, with the option to localize the display offset to local time or show UTC - with a hover tooltip of the 'opposite' (tooltip shows UTC if you're using localized, or tooltip shows localized if you're using UTC).

[aleghart]

Consistency and sorting: YYYY-MM-DD-HHMMSS
Stored: UTC
Event logs: switchable between UTC and local when you export.
Thing presented to humans: local.

[llamafilm]

I like 2024-06-02 22:26:50. No T between date and time, no microseconds, and no timezone.

I like how Grafana handles timezones. It's a user preference which defaults to "browser". It's displayed small in the corner of every page in case you forget or want to verify. If I am working together with someone in a different region, I can temporarily change my timezone to match theirs.

I actually just opened an FR for this before I noticed this discussion. #16381

[AliMickey]

+1 on client side timezone preferences, we have staff in different locations as do many companies, and having to use UTC is very cumbersome.

Having a user settable timezone or defaulting to browser preference and converting to/from UTC for the DB would be very nice.