5 ms·
Sure, you and others like you make pretty valid points. I believe we are talking about different use cases, hence the confusion. I was thinking of my most commo
by aulin 5y ago
Sure, you and others like you make pretty valid points. I believe we are talking about different use cases, hence the confusion. I was thinking of my most common use case of archiving events, usually experimental data, with a non ambiguous time reference.
If you need to schedule future events it gets obviously a lot more complicated, you don't need a timestamp you need local time and you need it to be robust to future changes in timezones, DSTs, politics.
- mlyle 5y agoBasically, it's important to recognize what you're actually measuring/capturing and store something maximally equivalent to that. Conversions may render figuring things out later impossible or very difficult. If you care about a past moment in time as reported by GPS or a computer clock-- use a UTC timestamp. If you care about a future time delineated by a precise interval from now-- use a UTC timestamp. If you care about a future time expected to be delineated in a specific time zone, use a timestamp in local time and note the zone. If you care about a future time in a customer's time zone no matter where they may be, store the time in an unspecified local time and the customer for whom the time applies. Etc.