Timeline for Simulating different times of day when running integration tests, .NET/XUnit
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 19 at 7:27 | comment | added | Flater | @ArseniMourzenko: As per my original point, not every application caters to users in multiple time zones especially corporate codebases with only one main branch. Again, having to repeat this because it doesn't seem to get across: I'm not saying your (or Caleth's) scenarios don't exist, nor that your advice is bad in those scenarios; I'm merely saying that you are discounting a significant amount of different scenarios that also exist but just don't fit with the advice being given here. | |
| Apr 18 at 7:44 | comment | added | Arseni Mourzenko | @Flater: it is specifically in the context of a date being seen by people that correctly managing TZ is important. People have a tendency to move to other countries or cities, as well as not using the same TZ as a properly configured server (that is, UTC). I wasn't even thinking about calculations when writing my answer. | |
| Apr 18 at 0:09 | comment | added | Flater | @Caleth "you now have a complex time of finding the interval between them" I'm not disagreeing with your technical opinion, I'm saying that you're talking about a different context than I am. As per my previous comment: "When a datetime's only purpose is to be seen by people, not logic, ..." As a fixed point in time without logic or calculations being operated on them, you can (and a lot of applications do) ignore the timezoned nature of a non-UTC datetime. Therefore, when given a random codebase, I would not blindly assume it is UTC like this answer suggests OP should do. | |
| Apr 17 at 10:45 | comment | added | Caleth | @Flater And I'm saying that just using local time doesn't help. Local time is almost always in two time zones. If you can't attach the timezone, then make sure you are using a timezoneless time, i.e. UTC. Otherwise if you store multiple points in time, you now have a complex time of finding the interval between them. | |
| Apr 17 at 9:38 | comment | added | Flater | @Caleth: Compare the point you just made to the direct quote from this answer I was responding to. Not caring is what I'm talking about, which is the opposite of actively assuming the time must be in UTC; hence my response. | |
| Apr 17 at 8:09 | comment | added | Caleth | @Flater Most applications will use the language provided DataTime type, which should be TZ aware. And then they don't have to care. | |
| Apr 17 at 6:38 | comment | added | Flater |
@Caleth: Not every application cares about considering how DST impact a time-zoned date. When a datetime's only purpose is to be seen by people, not logic, you can just state e.g. 3:00pm without needing to care about whether it's DST or non-DST. To be clear, I'm not saying that we should explicitly consider the avoidance of timezones a better overall decision, but I am saying that it is avoided way more frequently than this answer suggests.
|
|
| Apr 16 at 8:27 | comment | added | Caleth | @Flater Even if it's restricted to a single building, almost everywhere transitions between two timezones. Daylight savings is a time-zone change. | |
| Apr 16 at 7:24 | comment | added | Arseni Mourzenko | Think of it as Unicode vs. ANSI encoding. Given that in most cases, the reasoning was exactly that: “is just a simple business application, we don't need Unicode.” And sooner or later, big problems arise, and one needs to rewrite a lot of code. Just use Unicode but default, unless there is a strong reason not to (such as in embedded software). | |
| Apr 16 at 7:24 | comment | added | Arseni Mourzenko | @Flater: As I said, cases where timezone-aware objects cannot be used are rare—mostly legacy systems and embedded stuff. As for the “ton of simple business applications,” they specifically should use TZ-aware objects: it has a nearly zero cost, and avoids all sort of problems (1) when the company expands to another country (or even city, in the US!), or (2) when one employee happens to work remotely, or (3) the app is moved to a server in a different TZ and that is wrongly configured to use local time. | |
| Apr 15 at 23:44 | comment | added | Flater | "In the rare cases where you absolutely cannot use timezone-aware date and time objects (some old database system, maybe), always assume it's UTC." While this is good advice in the sense that it help to disambiguate things; I want to point out that it is not realistic advice for everyone. There are a ton of simple business applications intended to be used on a tiny scale within the same timezone, and it doesn't always make sense to introduce different-than-local times (whether timezoned or UTC) into the business logic. It's effort for sometimes no reward. | |
| Apr 15 at 22:37 | history | answered | Arseni Mourzenko | CC BY-SA 4.0 |