5 ms·

Only true if you ignore timezones and DST (which most people do because it is unholy mess) or stick to UTC.

by andy-x 6y ago

mywittyname 6y ago
You don't need to stick to UTC, you just need to stick to a single timezone. Which is something that is generally true. UTC just happens to be a good natural choice for eliminating timezones, but I've seen companies chose another tz as their standard.
- skissane 6y ago
  > UTC just happens to be a good natural choice for eliminating timezones, but I've seen companies chose another tz as their standard. If you are developing software purely for internal use, that might be okay. But I think it is bad idea if you are developing software for customers, including cloud-based services. There is a good chance at some point you are going to expose your internal timezone to the customer somehow, even by accident. If a customer in another country gets told something like "process X always happens at midnight UTC, and we can't change it", they'll generally be more accepting of that than if you say "process X always happens at midnight at our headquarters timezone, and we can't change it". The second makes you sound like you maybe don't take globalisation completely seriously. Even developing software purely for internal use, your headquarters timezone may change. Maybe the company gets acquired. Maybe it just decides to move to a lower cost or more business-friendly location (e.g. Oracle's recent relocation from California to Texas). A lot of stuff is going to stick with the old headquarters timezone because changing it is just too hard. But new stuff people may well choose the new headquarters timezone instead. Now you have two standard timezones to deal with! That's why: just leave everything as UTC internally. Convert to/from user's preferred time zone at time of display and data entry. That works for almost everything, except for applications which need to schedule meetings, work rosters, class timetables, etc. For those kinds of applications, the application needs to actually save the timezone with the data, and support different records belong to different timezones.
shpx 6y ago
or until you get into 5 digit years
- aairey 6y ago
  NMP. :D
  - shpx 6y ago
    It can be a problem/nuisance if you're working with nuclear waste or orbits. It's also ironic how programmers are surprised by the passage of time when it's one of the only things that's truly guaranteed.
    - dxdm 6y ago
      > It's also ironic how programmers are surprised by the passage of time when it's one of the only things that's truly guaranteed. Things you take for granted are easy to overlook until they break.
    - ProZsolt 6y ago
      Not if you traveling by the speed of light
Delk 6y ago
In many contexts that doesn't really matter. Sure, from a programmer point of view that's a problem because there are potential cases with incorrect or ambiguous behaviour, but being able to sort files by date could be useful in cases where that level of correctness and granularity don't matter. You might just have a bunch of files from around the year that you just know won't ever be that close together in time, and which you perhaps also only ever touch manually, not programmatically. I once chaired a smallish organization, and I used to name the minutes of meeting files with ISO 8601 style. If you have a dozen or so files from throughout the year, having them reliably sorted can make them easier to find, but there's never a problem with time zones or basically anything with granularity greater than a day. Usually, if you've got a situation where you need to worry about time zones or DST, identifying things with year-month-day style timestamps treated as strings would be too low-tech a solution anyway. (FWIW, the practice of using ISO 8601 didn't last, presumably because non-technical people didn't find them that nice for one reason or another.)

Only true if you ignore timezones and DST (which most people do because it is unholy mess) or stick to UTC.

by andy-x 6y ago

Only true if you ignore timezones and DST (which most people do because it is unholy mess) or stick to UTC.

You don't need to stick to UTC, you just need to stick to a single timezone. Which is something that is generally true. UTC just happens to be a good natural choice for eliminating timezones, but I've seen companies chose another tz as their standard.

skissane 6y ago
> UTC just happens to be a good natural choice for eliminating timezones, but I've seen companies chose another tz as their standard. If you are developing software purely for internal use, that might be okay. But I think it is bad idea if you are developing software for customers, including cloud-based services. There is a good chance at some point you are going to expose your internal timezone to the customer somehow, even by accident. If a customer in another country gets told something like "process X always happens at midnight UTC, and we can't change it", they'll generally be more accepting of that than if you say "process X always happens at midnight at our headquarters timezone, and we can't change it". The second makes you sound like you maybe don't take globalisation completely seriously. Even developing software purely for internal use, your headquarters timezone may change. Maybe the company gets acquired. Maybe it just decides to move to a lower cost or more business-friendly location (e.g. Oracle's recent relocation from California to Texas). A lot of stuff is going to stick with the old headquarters timezone because changing it is just too hard. But new stuff people may well choose the new headquarters timezone instead. Now you have two standard timezones to deal with! That's why: just leave everything as UTC internally. Convert to/from user's preferred time zone at time of display and data entry. That works for almost everything, except for applications which need to schedule meetings, work rosters, class timetables, etc. For those kinds of applications, the application needs to actually save the timezone with the data, and support different records belong to different timezones.

shpx 6y ago

or until you get into 5 digit years

aairey 6y ago
NMP. :D
- shpx 6y ago
  It can be a problem/nuisance if you're working with nuclear waste or orbits. It's also ironic how programmers are surprised by the passage of time when it's one of the only things that's truly guaranteed.
  - dxdm 6y ago
    > It's also ironic how programmers are surprised by the passage of time when it's one of the only things that's truly guaranteed. Things you take for granted are easy to overlook until they break.
  - ProZsolt 6y ago
    Not if you traveling by the speed of light

Delk 6y ago

In many contexts that doesn't really matter. Sure, from a programmer point of view that's a problem because there are potential cases with incorrect or ambiguous behaviour, but being able to sort files by date could be useful in cases where that level of correctness and granularity don't matter. You might just have a bunch of files from around the year that you just know won't ever be that close together in time, and which you perhaps also only ever touch manually, not programmatically. I once chaired a smallish organization, and I used to name the minutes of meeting files with ISO 8601 style. If you have a dozen or so files from throughout the year, having them reliably sorted can make them easier to find, but there's never a problem with time zones or basically anything with granularity greater than a day. Usually, if you've got a situation where you need to worry about time zones or DST, identifying things with year-month-day style timestamps treated as strings would be too low-tech a solution anyway. (FWIW, the practice of using ISO 8601 didn't last, presumably because non-technical people didn't find them that nice for one reason or another.)