4 ms·

There was another discussion here 10 months ago after Zach Holman's post: https://news.ycombinator.com/item?id=17181046 https://news.ycombinator.com/item?id=171

There was another discussion here 10 months ago after Zach Holman's post: https://news.ycombinator.com/item?id=17181046 https://news.ycombinator.com/item?id=17181046 Sort of a summarization of most of the ideas here is: * for clear instants like a system log UTC makes sense * for times in the past (far enough in the past that you know your current TZ rules are correct) UTC makes sense. * for the immediate past (near enough where your rules might not be correct) you might want to store zone as well. For all cases of times in the past, remember that you're trying to record an instant. An exact unambiguous point in time that is the same irrespective of who is looking at it or where they are. For this UTC makes sense - people who see that instant converted to their local timezone are noting what their clocks would have shown at that instant, but everyone who will ever see it is always referencing the same instant. FUTURE times are very different. There are times at which you want to reference a future instant, at which point you can just use UTC, but most often what you really have is "this is what I expect to see on my wall clock when this thing happens". That is a very different beast, because nobody knows what the timezone rules or geopolitical situation will be when that thing does happen. You need to recognize the use cases where what you mean is " I expect to see XX:YY:ZZ on my wall clock when this happens" and just record that information as is, including as much information as you can about that wall clock - possibly which timezone it (currently) uses, where it is (in case the timezone itself changes) and then convert to an instant at the last possible moment, or keep updating your instant based on changing rules.

IgorPartola 8y ago
There is one thing that I ran into with past times that I think falls outside of this. When you record things like “first day of employment”, you really do mean the date and not the datetime, and the date should be interpreted in whatever the local timezone is. Theoretically your first datetime if employment is what, midnight of the day you show up? Or is it 8am or whatever when you actually first step through the door? Each situation will be interpreted differently by the parties involved so best you can do is to store the date and the location/timezone of where they work, even though it’s in the past.
- sudhirj 8y ago
  Yeah, a date and datetime / instant are two very different things, but I just renewed an insurance policy, and while it's been all dates on the forms so far the actual policy documents is clear about midnight to midnight on those dates. In the particular case of employment I'd assume there was as implicit time as well, because employment would be a legal contract (whatever the precedent is in that jurisdiction would probably apply). You couldn't do something that's against your contract on the way to work on your first day, for example, and claim that it didn't count because it was before office hours.
- PeterisP 8y ago
  The answer to your examples is that the conversion from date to datetime sometimes is ill-defined and you shouldn't assume that this can be properly done. Legally, employment usually has a well defined start date and end date - and it often simply doesn't have a well defined start datetime and an end datetime, you might as well assume that it's undefined unless/until a particular situation forces you to get a court ruling for that.
  - IgorPartola 8y ago
    How would you for example run payroll then for people who work 4pm-2am? You have to know whether the last two hours of the shift fall into one payroll period or the next, which necessitates that you be able to convert to a datetime.
bradstewart 8y ago
Ran into the "fun" around future dates big time at my previous company. We allowed users to define schedules which would control light, temperature, co2, irrigation, etc for greenhouses. Those schedules would load into on premise controllers and run for weeks or months. They might be built by a user in one timezone and deployed to multiple facilities in different timezones. They often ran across DST boundaries, and some users wanted them to follow "wall clock time" while others wanted to ignore DST to match the behavior of legacy control systems.

IgorPartola 8y ago

There is one thing that I ran into with past times that I think falls outside of this. When you record things like “first day of employment”, you really do mean the date and not the datetime, and the date should be interpreted in whatever the local timezone is. Theoretically your first datetime if employment is what, midnight of the day you show up? Or is it 8am or whatever when you actually first step through the door? Each situation will be interpreted differently by the parties involved so best you can do is to store the date and the location/timezone of where they work, even though it’s in the past.

sudhirj 8y ago
Yeah, a date and datetime / instant are two very different things, but I just renewed an insurance policy, and while it's been all dates on the forms so far the actual policy documents is clear about midnight to midnight on those dates. In the particular case of employment I'd assume there was as implicit time as well, because employment would be a legal contract (whatever the precedent is in that jurisdiction would probably apply). You couldn't do something that's against your contract on the way to work on your first day, for example, and claim that it didn't count because it was before office hours.
PeterisP 8y ago
The answer to your examples is that the conversion from date to datetime sometimes is ill-defined and you shouldn't assume that this can be properly done. Legally, employment usually has a well defined start date and end date - and it often simply doesn't have a well defined start datetime and an end datetime, you might as well assume that it's undefined unless/until a particular situation forces you to get a court ruling for that.
- IgorPartola 8y ago
  How would you for example run payroll then for people who work 4pm-2am? You have to know whether the last two hours of the shift fall into one payroll period or the next, which necessitates that you be able to convert to a datetime.

bradstewart 8y ago

Ran into the "fun" around future dates big time at my previous company. We allowed users to define schedules which would control light, temperature, co2, irrigation, etc for greenhouses. Those schedules would load into on premise controllers and run for weeks or months. They might be built by a user in one timezone and deployed to multiple facilities in different timezones. They often ran across DST boundaries, and some users wanted them to follow "wall clock time" while others wanted to ignore DST to match the behavior of legacy control systems.