Comment by sholladay
3 days ago
Personally, I like that UTC is the default time zone. Processing of dates should happen in a standardized time zone. It’s only when you want to display it that the date should become local.
3 days ago
Personally, I like that UTC is the default time zone. Processing of dates should happen in a standardized time zone. It’s only when you want to display it that the date should become local.
UTC is a fine default time zone, but that doesn't matter here.
A datetime with a timezone and a datetime without one are two different things, both of them useful. My birthday does not have a time zone. My deadline does.
The company deadline for getting some document returned? It might or might not, that's policy.
Poetically: we are born free of time zones. We die bound to one.
> My birthday does not have a time zone. My deadline does.
That seems subjective
It doesn't to me. It should be obvious that there are plenty of valid uses of dates and times which implicitly refer to either an exact instant in time, or the expression of a time in a certain reckoning.
A birthday doesn't have a time zone because the concept of a birthday is more about the date on the calendar on the wall, not any universally understood singular instant in time; and so what matters most when it comes to your birthday is where you are. Your birthday doesn't move to the day before or after just because you travel to the other side of the globe.
A deadline has a time zone because when your boss says he wants the project done by 4PM, he means 4PM wherever you both currently are -- and the specific instant in time he referred to doesn't change if you get on a train and move a time zone over before that 4PM occurs.
And it may in fact be time zone and not just UTC with an offset; because if your boss tells you he wants a certain report on his desk by 4PM every day; when your local time zone goes into daylight saving time, it doesn't suddenly mean the report needs to be filed by 5PM instead.
In the first of these cases, the date itself has no time zone and is valid in whatever context its being read from. In the second, the instant in time might be expressed in UTC time with or without a specific offset. In the third, each of the successive instants in time may shift around with respect to UTC even while it continues to be referred to with one constant expression.
None of these are subjective interpretations. They're a consequence of the fact that as humans we've overloaded our representation of date/time with multiple meanings.
1 reply →
It does not. I'm Australian and our timezones are ahead of the US (NSW time is about 15-17 hours ahead of US Eastern time). If I took a flight from Sydney to New York (22~ hours) on my birthday, the US custom's officer would wish me happy birthday when I landed the next day.
Therefore, birthdays are not bound by timezone at all.
1 reply →
This will result in incorrect behavior when, between converting to UTC and back to the original timezone, the timezone database has changed, which happens more often than you think.
If time is stored in UTC, the result is correct even if the timezone database is corrupted, because timezone is only metadata and doesn't affect time.
Depends what you're actually storing. There are plenty of cases where the timezone is not metadata; it defines how the datetime should be interpreted.
For example: your local mom and pop corner store's daily opening and closing times. Storing those in UTC is not correct because mom and pop don't open and close their store based on UTC time. They open and close it based on the local time zone.
2 replies →