Bill Moseley wrote:
> I don't want to drag discussion on too much longer, and moving way off
> the original topic...
I don't see this discussion drifting off topic. I see it now getting to
the very heart of the matter.
> In a web app a user might enter a time, say 9:00am in the future, when
> some event should happen. We know their timezone is America/New_York.
>
> So, we create a DateTime object DateTime->new ( hour => 9, time_zone =>
> 'America/New_York', ... );
>
> Then we use DateTime::Format::Pg to format that to store in a "timestamp
> with time zone" column.
>
> Am I correct that DateTime (or the formatter) does its best to determine
> the *offset* from UTC at that time in the future and stores that?
>
> Would you implement that differently?
Offsets from UTC don't record any useful information about time zones.
For the kind of scheduling application you're describing, an offset from
UTC isn't helpful because it doesn't record the important information
you need to know about the future point in time at which something must
occur; namely, where—in what geopolitical locale, or time zone—the user
is asserting that some event must occur in the future.
This is one of the reasons that, for the purpose of storing moments in
time in a computer database, it's better to normalize their
representation to a single reference time scale such as UTC. At the very
least, doing this saves a lot of needless arithmetic with purposeless
offsets.
> But, between now and that future time politics could change DST resulting
> in the event not really happening at 9am in New York on that day, correct?
> That's a risk.
>
> There's too many ambiguities. Does the user really mean 9am in New York?
> Or 9am in whatever their current time zone is on that day? Maybe in this
> case should really store with a local time zone "9am America/New_York".
>
> Probably best to not schedule anything too far into the future...
You can't reliably represent a future RELATIVE moment in time such as
noon in Caracas, Venezula on October 12, 2018 using an ABSOLUTE instant
you assert today. You can't be certain right now which instant noon will
be on that future date in Caracas. So just guessing an ABSOLUTE instant
now and storing that guess in a computer database won't suffice for the
purpose of signaling some event to occur at that RELATIVE moment in the
future and in that place—or in any other place at that same instant
reckoned from noon in Caracas on October 12, 2018.
You can, however, reliably represent future RELATIVE instants in
computer software. You just need a protocol to do this. Storing
ABSOLUTE timestamps alone—using any time scale or in any time zone—
won't cut it. You can invent your own protocol, or you can use an
existing one such as iCalendar. I believe iCalendar (RFC 5545) is
designed to enable exactly the kind of RELATIVE time representation
for scheduling events that you describe.
The Perl DateTime documentation states: "The default time zone for new
DateTime objects, except where stated otherwise, is the 'floating' time
zone. This concept comes from the iCal [iCalendar] standard."
The iCalendar standard defines three kinds ("forms") of times:
FORM #1: DATE WITH LOCAL TIME ("floating")
FORM #2: DATE WITH UTC TIME
FORM #3: LOCAL TIME AND TIME ZONE REFERENCE
(See http://tools.ietf.org/html/rfc5545#page-31.)
I believe this is how you might represent the RELATIVE time noon in
Caracas on October 12, 2018 using the iCalendar standard:
DTSTART;TZID=America/Caracas:20181012T120000
The iCalendar standard specifies how to handle daylight/standard time
boundary cases such as when the same time occurs twice on the same day,
or when a time doesn't occur on a transitional day—like today in most
of the United States!
Needless to say, there are plenty of Perl CPAN modules for handling
iCalendar data, including DateTime::Event::ICal.
(Disclaimer: I don't know the iCalendar standard well and I've never
done the kind of scheduling software programming we're discussing here.
What I've written in this email is based on the little research I did to
try to answer your questions as best I could. If, knowing this, you say
I should have kept my pie hole shut from the beginning, I won't argue
with you. Hopefully, however, I've contributed at least one useful idea.)
--
Jim Monty
Tempe, Arizona USA
