Split time zone calculations and formatting

[moll]

Hey,

This is a good and convenient library for getting the time in another time zone. But what the heck is it doing formatting and returning strings? These are two entirely orthogonal use cases and should be in separate functions, if not separate libraries. We've already got n+1 string and date formatting libraries. We don't seem to have decent time zone libraries. At least I haven't found any.

Last I checked it was not possible to get an array of numeric time values out of the main function here? I've resorted to splitting a string of year, month etc. values. I hope you agree that it quite nuts to first turn numbers into strings based on a format string and then turn that little serialization format back into numbers. ^_^

Or am I missing something obvious and it's easy-peasy to get back the plain old date field numbers in a given time zone for any given UTC time? Thanks!

[bigeasy]

So, you saw this and you take issue with it?:

http://bigeasy.github.io/timezone/#section-162

[moll]

Absolutely. It's an insane workflow. :)

[bigeasy]

The reasoning behind it is this; wall clock time is a localization problem, it is defined by polity not by science, it is very human. It seems to me that most people would look to display the clock on the wall.

The existing representation of wall clock time that is any sort of standard are the RFC and ISO dates and those are strings. The date offset is part of a string.

If you wanted to indicate a timezone to your dear user, you would display that as a string, not as an offset.

These are the reasons that pointed toward a string as a primary expression of wall clock time. It is really a language construct more than programming construct.

Note that Timezone really implements strftime, so there again Timezone is able to build on top of an interface defined by a successful standard.

The date picker array was added for date picker applications.

There is a boundary where Timezone cannot be all things to all people. It's interface is based on existing date formats RFC and ISO time, and strftime. Yes, there are other JavaScript libraries that can do more with formatting, but the choice of strings is more of a standards choice.

It was always intended that you could easily shim the tz function to convert this universal type. If you had a bunch of dates in a log file without a timezone, you wanted to do date math on them, and you knew those dates to be in a specific timezone, it would not be up to Timezone to be a universal parser-guesser. You'd convert the date in the file to an ISO date with the correct timezone offset before giving it to Timezone.

ISO date is a string, but it is an explicit string. It is a language and Timezone is an interpreter.

Then, conversely, timezone emits strftime. strftime was the only Timezone aware formatting language I could find for UNIX. I used it because it was there.

I don't feel that it is "insane." I feel that you have a strong opinion. I don't believe that it is nuts to go from a string to an array, any more than I would think that it was nuts to return, say, an object with named properties and convert that to an array, if an array is what your application prefers to work with.

That is a presentation of the reasoning behind Timezone.

We've already got n+1 string and date formatting libraries. We don't seem to have decent time zone libraries. At least I haven't found any.

That is compelling.